Combining UML and Z in a Software Process

Size: px
Start display at page:

Download "Combining UML and Z in a Software Process"

Transcription

1 Combining UML and Z in a Software Process Ebba Thora Hvannberg University of Iceland, Reykjavik, Iceland, ebba@hi.is Abstract: Observing students writing specification in UML and Z has motivated the work presented in this paper. There is a need to add formal specification to diagrammatic notations such as UML and there is even a greater requirement to examine where in the software life cycle Z specifications are most useful. The Z language allows us to use abstraction in software development but UML has rich constructs for modelling systems with concise diagrams. Languages are only islands and need to be accompanied with methods that show their usage in a process. The Unified Process has been developed to use with UML. This paper examines how UML can be augmented with Z and where in the Unified Process Z specifications fit best. Keywords : software process, UML, Z, formal specification, diagrammatic notation 1 Introduction When giving a course on formal methods in software development I have twice tried to compare the benefits and drawbacks of UML (Unified Modeling Language) [1] and Z formal specification language [2]. UML is a language that describes static models in class diagrams that includes attributes of classes, methods and relationships between classes. UML constitutes a set of diagrams for behaviour of software systems as well as components and packages. The Z language is based on propositional and predicate calculus. It can model problems or systems as sets, relations and functions. Schemas express states with data invariants or they express transformations with pre and post conditions. The constraints denote what needs to be true before the transformation on the state takes place and what is true after the transformation has been realised. The comparison has been realised by giving separate assignments in UML and Z. The first time I wanted to contrast the two methods I asked students to do a problem with one methodology and then again using the other. Students were divided into two groups A and B. Students in group A started to solve the problem with UML, following with Z, and students in group B started with Z and followed with UML. Students in group B didn t get to the second part since so much time was spent on writing the Z specifications. Students in group A found it time consuming to do the assignment again in Z once they had already done it in UML. The developers couldn t reuse directly much of the specification that they had already carried out. The second time the course was offered, I had another arrangement. There were several different problems to solve and any student was to do one exercise in UML and another in Z. The problems were real, some suggested by the students themselves. The intentions were to compare the number and types of errors the students made in the assignments. This proved difficult because it was hard to determine what constituted an error in a consistent manner. Comparing errors in UML and Z would not have been meaningful. The characteristics of each of the methodologies and the approaches the students used were observed. Few of the observations will be mentioned below. The learning curve for formal specification is steeper than for diagrammatic approaches. It was observed that if students do not have a lot of experience in modelling software they have problems with both UML and Z. Many of the students work in industry and they objected to model the problem in Z. This was not always rooted in the Z notation itself but modelling in general. If developers are experienced, they can use either UML or Z but Z will probably take longer. The reason is that there are more rules to follow in the Z language and because the semantic richness of the languages forces you to specify and discover more of the problem. The tools for UML are more accessible than Z. Students find it more permissible to break the rules when using UML. It seems that since the language is less formal than Z they tend to think it is all right to break the rules of the grammar. Many of them choose to use a regular drawing tool for UML so that they can be more relaxed with notation and prefer only the UML language specific tools if they intend to generate implementation automatically from design. Students seem to have difficulties in forming states or schemas in Z since they did not have any methodology to determine what constituted a schema. In object-oriented modelling they have some rules to follow, such as making a list of candidate classes from nouns.

2 Having used and taught both UML and Z has motivated us to combine the two languages in a software process lifecycle. The first approach to the problem was to try to see where in the life cycle developers should use Z and where they should use UML. We have since come to realise that there must be a stronger connection between the two languages. Specifications or declarations in one language should be reusable in the other. The next section specifies the requirements for the combination of UML and Z and the third section describes the selected approach. The strength of Z and the weakness of UML are described in sections four and five respectively. Section 6 discusses Z augmentations for each of the UML constructs. The seventh section describes processes for the combined languages. 2 Requirements A specification and design method calls for several characteristics. The foremost characteristic is abstraction, that is the ability to describe some thing in the real world without specifying details. An example would be an invoice. We need to be able to say that there are objects of type invoice without saying what characteristics it has or behaviour. In later stages, we need to be able to refine the abstraction in small manageable steps. A specification needs to be verifiable and traceable. We need to verify that a design meets a specification that fulfils requirements and need to do so in a traceable manner. The verification can only be done effectively, if the specification is unambiguous. Another reason for specifying software formally is that the specification becomes shorter, the reader is quicker to see the definitions and the he has to spend less time asking the same questions. The designer needs to feel that something is gained by specifying software formally and therefore he is happy if the design maps easily to an implementation and preferably automatically. Developers should be able to master the method quickly and be able write specifications and designs. Many think that at least buyers and even users should be able to easily read a specification. Finally, the method needs to have a formal meta-model so that one can specify its semantics. 3 A selected approach During software specification and design, it is an advantage to follow a process that guides us through the methodology. We can have languages such as UML and Z but they are no good unless we have a process. The reason we used Rumbaugh s book [3] as reference in a course on software design some time after we had stopped using OMT (Object Modelling Technique) and transferred to UML is that it contained best practices and a process for applying OMT. One of the process frameworks used for UML is The Unified Software Development Process (UP) [4]. The Cleanroom method also has a process framework as described in [5]. The lack of process has undoubtedly been a weakness for Z, since textbooks often cover the language with examples and case studies but not a process that dictates where in the software development life cycle it should be used and how it is connected to other artefacts or sub processes. Most books describe though how you go from abstract specifications to detailed refinements. The OMT method that is the predecessor of UML language assumed that we went directly into analysis with diagrams and didn t write any text. Functions were a taboo since the emphasis was on objects, their attributes and actions. Later with UML it was permissible to write use cases that are a kind of tasks or functions. Use cases serve the valuable purpose of describing the dialogue between the system and the user. Use cases can be refined into application use cases, where artefacts and actions in the dialogue have been refined into GUI objects and actions. Although not a part of UML, there is a convention of describing use cases with text with pre- and post conditions. Z can easily play a larger role early on in the software life cycle by defining predicates for use cases, but they have to be very abstract. Furthermore, it is important to be able to use schemas as classes in the UML notation. Traceability between the Z notation and UML is also imperative. OMG has specified a constraint language, Object Constraint Language (OCL) [6] that allows you to specify pre and post conditions as well as invariants. These are specified in brackets and can be placed anywhere in the diagrams. The language is disputable [7] and researchers are identifying its shortcomings [8]. One of the objectives of OCL is to allow specification of constraints but in a less formal language than Z. In the past when hurdles have been encountered in software development, various approaches have been taken. The most popular method is to make a tool. Unfortunately, this may be expensive if the user base is not large. A second method is to have a library of functions or components that we can search for solutions. Finally, a third method is to have patterns that we can populate or frameworks. Patterns for design solutions have been presented in UML and Z bases its language on a library of functions. Tools that implement Z have unfortunately not been that successful. Patterns of software life cycle processes may be helpful where developers can see where they need to augment UML with Z. There could be different patterns of software life

3 cycle processes for different types of software. Strict requirements to safety and security mandate specification that is more formal. 4 Strength of Z Behavioural specification, i.e. describing how things change is the strong side of Z but at the same time the weak side of UML. In UML, we can express state changes, collaboration, and workflow, but we cannot describe how objects change in terms of transformations. The strong side of UML is simplicity and the weak side of Z is a lack of graphical notation. The key to success in software development is to postpone the refinement as long as possible. If we are to model a file directory we can simply write it first as a set of FILEs. We can postpone the definition of a function that identifies a file by its name. When teaching students Z specification, the author has found it most useful to ask them to write specification in a natural language first and then introduce simple logical operators, followed by quantifiers and variables for predicates. Z is strong on sets and functions. It is for exa mple very easy to specify sequences and bags but in UML you cannot make this distinction when you specify relationships. 5 Weakness of UML UML s weakness is that it lacks in richness in specification. UML does not allow us to specify behaviour well in terms of how activities transform one state to another. For example when adding VAT to total price it is not easy to specify that the total price is the base price multiplied with VAT and the VAT can be either 14,5% or 24,5% depending on the type of goods. Such transformation rules and other constraints often come up in the analysis phase in the discussion with the user or the customer. Second, one cannot specify that one attribute or object be derived from another that is that the values are extracted from another attribute. An example of this is the creation of an invoice from an order of goods and we need to copy the product items from the order to the invoice. In UML, we can specify that an invoice relates to a product and that an order relates to a product, but nothing indicates that the product is the same one in both cases. 6 UML augmented with Z UML is used throughout the software life cycle. All the UML constructs can be used in requirements, analysis and design and testing. Furthermore, some tools derive implementation from class diagrams. Requirements specification involves specifying the business model but analysis is a more precise specification. In this section, we describe how UML can be annotated with Z. We avoid discussing software life cycle processes in this section except we indicate how it is useful to use iteration in the UML and Z specification within the analysis process. The following section explains the different emphasis of UML or Z in the various life cycle processes. 6.1 Use cases Use case texts are not a part of UML but templates that describe the texts typically include a name, an identifier, a pre and a post condition, a description and exceptions. In use cases text we propose to use Z for pre and post conditions to capture changes of states and data invariants. In order to do this we may identify some sets and schemas that capture states. Propositions and predicates are used to express pre and post conditions of use cases as well as their descriptions. Use case diagrams give a good overview of the use cases of a system. They also allow us to specify two types of relationships between use cases, that is extends and uses. The use case diagrams can be annotated with a Z pre and post conditions. 6.2 Static modelling In the first iteration of class diagrams, we identify classes with attributes. No associations are allowed. We can write Z specifications of relations and function signatures. Z schemas that capture states will also start to appear during the first iteration. Classes in UML are often Z schemas and vice versa. In the second iteration of class diagrams, UML associations can be derived semi -automatically from Z relationships and functions. In the third iteration of class diagrams methods are added to class diagrams as they materialis e in the behavioural diagrams. Note that the third iteration is most often written after behavioural modelling has taken place as is discussed in the next subsection. If the Z pre or post conditions have not been specified during the drawing of the diagrams, they are written in this iteration.

4 6.3 Behavioural modelling In UML there are two main categories of behavioural diagrams, state and interaction diagrams. State diagrams can be either conventional state diagrams or activity diagrams. Interaction diagrams can be either sequence diagrams or collaboration diagrams. Normally, we decide the actions of the classes after drawing the behavioural diagrams. One approach is to specify the actions with Z specifications and some functions have been identified in the use cases. Below, we discuss how behavioural diagrams can be augmented with Z specifications. An essential prerequisite is that we have specified the Z types (or schemas) on which to work during the first and second iteration of writing class diagrams. An activity diagram allows you to specify that an object be updated by writing an arrow from a state to an object, but not how. The update will be specified with Z. State diagrams allow us to specify what actions transform a state to another. We can name the states but we cannot specify what changes. For example if an order is filled it goes from being placed to being filled, but we cannot specify the side effects, such as that the goods should be withdrawn from supplies. Sequence diagrams are used to specify the interaction between the user and major objects of the system in a series of steps where one starts at the top and proceeds down the page as time passes. The major actions could be annotated with Z specifications of post conditions. The sequence diagrams are often used to show the user a series of actions during analysis. Collaboration diagrams are used to denote how the objects are glued together. Collaboration diagrams show a series of numbered action calls between objects. Although collaboration diagrams can be used during analysis, they are perhaps better suitable for design. Our hypothesis is that it may not be suitable to annotate the actions with Z specifications, but to specify them separately with pre- and post conditions. The key to the integration between UML and Z as described in this section is that we specify the sets, relations and functions along with the class diagrams. Furthermore, we need to enhance as much as possible automatic derivation of one form from the other. As mentioned previously it is vital that the two methods are integrated. However, this can be difficult since their presentation form is very different. One is a drawing and the other is mathematical specification. We know from experience that the application of the method can promote or demote its usage. Beginners usually prefer graphical user interface and like to draw but specialist like more succinct presentation of commands. This is surely one of the reasons, formal methods have few followers and it is so difficult for people to get started. With XML, ( we may have a technology that allows us to represent both forms in one document and more easily link those together. We hope that XML will also give us better traceability between items of the two languages. UML has a well defined meta-model and thus an UML definition can be translated into an XML document. Undoubtedly, we will be able to specify Z in an XML document in the future. 7 Modified processes for UML with Z The characteristics of the Unified Process are that it is use case driven and architecture centric. That it is iterative means that artefacts are delivered in increments. Finally, it is risk driven, that is every step of the way we try to identify the risks and control them. The question that is fore us is how adding formal specification to UML supports the characteristics or if the addition motivates any changes to the process. We will discuss in the following three subsections how Z supports the desired claimed characteristics of the Unified Process. In the fourth subsection, we will examine the different models of the Unified Process in an attempt to answer the above question. 7.1 Iterative and incremental In iterative software development the project is broken down into parts that results in increments being developed and then integrated to the rest. Adding Z does not add anything further in supporting this characteristic when iterations constitute increments in functionality. However, when we talk about increments in refinements Z will help us. Z encourages the developer to specify software abstractly. He or she may be able to develop simpler versions first and then more refined versions with other characteristics such as better performance. This is also a characteristic of the cleanroom process methodology. 7.2 Risk driven How Z supports the risk driven characteristic of the Unified Process is not clear. One can argue that it reduces risks since the specification is less ambiguous. When requirements elicitation sessions are observed, one sees that it can be time consuming when users or buyers ask the same questions. A written specification remedies this problem partially, but an informal text is not enough since developers tend to leave gaps in the specifications. Second, a formal specification may decrease risk since more time is spent on specification

5 and thus the developer is more likely to discover attributes and functions of the system. One can also counter argue that formal specification can increase risk since there is possibly not enough knowledge or training to apply it. 7.3 Architecture driven The Unified Process encourages developers to consider architecture early in the software life cycle. UML supports the specification of architecture through deployment diagrams and collaboration diagrams where collaboration between subsystems is shown. Z specifications can be added by placing transformations on edges that denote collaborations between components or subsystems. Architecture can further benefit from Z specifications by writing constraints on non-functional requirements such as performance, security or usability. Further support of Z to the architecture description has not been studied. 7.4 The Unified Process The second part of our exercise is to look at the various models of the Unified Process and describe how an embedded Z specification will change them and where. In order to have a complete analysis, one can look at a matrix where the models make up rows and the phases are columns. The models are: use case models, analysis, design, deployment, implementation and testing. The phases are inception, elaboration, construction and transition. As described in the Unified Process there are various amounts of effort carried out of the models in the different phases. For example, there is most emphasis on the use case model during inception, analysis model during elaboration, design and deployment models in late inception and early elaboration, and implementation during construction. The testing model is used in all the phases and verifies that the transition between models is correct as well as tests that the functional and non-functional requirements are met. Use cases hat are written during inception will benefit from having post-conditions written in Z as long as the major sets have been identified. This is the most drastic change since use cases have often not been specified very formally. The use case model constitutes the external view of the system, i.e. the contract between the buyer and the seller. Thus, it can be valuable to make it less unamb iguous with formal specification. A formal specification is traditionally most heavily used during elaboration where we perform analysis and start to design. Analysis can be described in the language of the developer and thus we have more freedom to use a formal specification language. Since a design is a refinement of analysis, it is only natural that we include formal specification there too. Although experience has shown that as we go nearer to design and the technical environment of the system, there may be less need for formal specification because of use of function from libraries, well known data structures and components. This is particularly true where we use ready-made components. In other cases the developers requires that Z specifications can be written along with the programs as comments. During design, there is more emphasis on breaking down activities into methods with pre- and post conditions. Furthermore, we have more behavioural diagrams such as state and interaction diagrams. If the design is critical such as in safety or security systems or commerce systems that require reliability because of possible monetary loss, we will be forced to specify the design formally. The implementation model is the most concrete one and most formal. Traceability to implementation is vital in order to be able to carry out testing. We will not assess whether formal specification should be a part of the test model. It is rather that the formal specification should be input to the testing model. The Cleanroom method has a good model for verification since it allows you to specify any sentence in a function as a set of states with predicates that captures the semantics of that state. 8 Conclusion This paper has presented an approach to augment UML with Z with emphasis on describing its use in the software life cycle. Students experience with using each of the methods has motivated the work. In our curriculum, we think it is important to teach students formal specification of software. It has proven a little difficult to do so in isolation of other methodologies such as UML that we teach. As is pointed out in [9], it is important that software developers receive mathematical training as a part of formal education since they are not likely to perceive it as an important skill to add later on during continuing education. Further work will demonstrate the ideas set forth here in examples and project assignments. When more experience will be gained, an evaluation of whether the requirements from section two have been met will be done. At the onset, we have stated that abstraction and a well-defined software process are keys to successful development. Experience shows that this also helps students with specification. In [9] Bertrand Meyer sets forth important body of software engineering

6 knowledge. The list of principles contains items that we have studied in this paper such as abstraction, typing and reuse but the list also includes items that we have left out. Further work should address how these items such as designing for change and exception and debugging are crystallised in UML augmented with Z. 9 References [1] Woodcock, Davies, Using Z, Prentice Hall, 1996 [2] Pooley, Stevens, Using UML, Addison Wesley, 1999 [3] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddi, W. Lorenson, Object-oriented modeling and design, Prentice Hall, 1991 [4] I. Jacobsson, G. Booch, J. Rumbaugh, The Unified Software Development Process, Addison Wesley, 1998 [5] C.J. Trammell, R.C. Linger, J.H. Poore, Cleanroom Software Engineering: Technology and Process, SEI Series in Software Engineering, 1998 [6] J. Warmer, A. Kleppe, The Object Constraint Language, Precise Modeling with UML, Addison Wesley, 1999 [7] M. Vaziri, D. Jackson, Some Shortcomings of OCL, the Object Constraint Language of UML, Response to Object Management Group's Request for Information on UML 2.0, December 1999 [8] J. Warmer and T. Clark editors, UML 2.0 The future of OCL, Report of the workshop held on October 2, 2000 York [9] B. Meyer Software Engineering in the Academy, IEEE Computer, May 2001

SRI VENKATESWARA COLLEGE OF ENGINERRING AND TECHNOLOGY THIRUPACHUR,THIRUVALLUR UNIT I OOAD PART A

SRI VENKATESWARA COLLEGE OF ENGINERRING AND TECHNOLOGY THIRUPACHUR,THIRUVALLUR UNIT I OOAD PART A SRI VENKATESWARA COLLEGE OF ENGINERRING AND TECHNOLOGY THIRUPACHUR,THIRUVALLUR UNIT I OOAD PART A 1. What is an object? An object is a combination of data and logic; the representation of some realworld

More information

Object-Oriented Software Engineering Practical Software Development using UML and Java

Object-Oriented Software Engineering Practical Software Development using UML and Java Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 5: Modelling with Classes Lecture 5 5.1 What is UML? The Unified Modelling Language is a standard graphical

More information

The UML Extension Mechanisms

The UML Extension Mechanisms Jasmine Farhad Dept of Computer Science University College London 13-Dec-02 The UML Extension Mechanisms Introduction There is an important need for organisations to evolve in today s market. This has

More information

Formal Specification of Software Systems

Formal Specification of Software Systems Formal Specification of Software Systems Lecture Notes Winter Term 2001 / 2002 Heinrich Hußmann Technische Universität Dresden Formal Specification of Software Systems Summary: Construction of large software

More information

Software Engineering with Objects and Components Open Issues and Course Summary

Software Engineering with Objects and Components Open Issues and Course Summary Software Engineering with Objects and Components Open Issues and Course Summary Massimo Felici Software Engineering with Objects and Components Software development process Lifecycle models and main stages

More information

NOTES ON OBJECT-ORIENTED MODELING AND DESIGN

NOTES ON OBJECT-ORIENTED MODELING AND DESIGN NOTES ON OBJECT-ORIENTED MODELING AND DESIGN Stephen W. Clyde Brigham Young University Provo, UT 86402 Abstract: A review of the Object Modeling Technique (OMT) is presented. OMT is an object-oriented

More information

Week 9 Implementation

Week 9 Implementation Week 9 Implementation Dr. Eliane l. Bodanese What is more important From a software engineering perspective: Good Gui? does what customer wants maintainable, extensible, reusable Commented Code? how is

More information

Chamberlin and Boyce - SEQUEL: A Structured English Query Language

Chamberlin and Boyce - SEQUEL: A Structured English Query Language Programming Languages (CS302 2007S) Chamberlin and Boyce - SEQUEL: A Structured English Query Language Comments on: Chamberlin, D. D. and Boyce, R. F. (1974). SEQUEL: A Structured English Query Language.

More information

Unit 1 Introduction to Software Engineering

Unit 1 Introduction to Software Engineering Unit 1 Introduction to Software Engineering João M. Fernandes Universidade do Minho Portugal Contents 1. Software Engineering 2. Software Requirements 3. Software Design 2/50 Software Engineering Engineering

More information

Software Engineering

Software Engineering Software Engineering A systematic approach to the analysis, design, implementation and maintenance of software. Software Development Method by Jan Pettersen Nytun, page 1 Software Engineering Methods Most

More information

Object-Oriented Software Engineering Practical Software Development using UML and Java. Chapter 5: Modelling with Classes

Object-Oriented Software Engineering Practical Software Development using UML and Java. Chapter 5: Modelling with Classes Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 5: Modelling with Classes 5.1 What is UML? The Unified Modelling Language is a standard graphical language

More information

CHAPTER 1. Topic: UML Overview. CHAPTER 1: Topic 1. Topic: UML Overview

CHAPTER 1. Topic: UML Overview. CHAPTER 1: Topic 1. Topic: UML Overview CHAPTER 1 Topic: UML Overview After studying this Chapter, students should be able to: Describe the goals of UML. Analyze the History of UML. Evaluate the use of UML in an area of interest. CHAPTER 1:

More information

Object-Oriented Systems Analysis and Design Using UML

Object-Oriented Systems Analysis and Design Using UML 10 Object-Oriented Systems Analysis and Design Using UML Systems Analysis and Design, 8e Kendall & Kendall Copyright 2011 Pearson Education, Inc. Publishing as Prentice Hall Learning Objectives Understand

More information

Software Development Methodologies

Software Development Methodologies Software Development Methodologies Lecturer: Raman Ramsin Lecture 3 Seminal Object-Oriented Methodologies: A Feature-Focused Review 1 Responsibility-Driven Design (RDD) Introduced in 1990; a UML-based

More information

Using the UML to Describe Design Patterns

Using the UML to Describe Design Patterns Proceedings of the 16 th Annual NACCQ, Palmerston North New Zealand July, 2003 (eds) Mann, S. and Williamson, A. www.naccq.ac.nz Using the UML to Describe Design Patterns ABSTRACT to describe patterns

More information

A Comparison of the Booch Method and Shlaer-Mellor OOA/RD

A Comparison of the Booch Method and Shlaer-Mellor OOA/RD A Comparison of the Booch Method and Shlaer-Mellor OOA/RD Stephen J. Mellor Project Technology, Inc. 7400 N. Oracle Rd., Suite 365 Tucson Arizona 85704 520 544-2881 http://www.projtech.com 2 May 1993 The

More information

FORMALIZED SOFTWARE DEVELOPMENT IN AN INDUSTRIAL ENVIRONMENT

FORMALIZED SOFTWARE DEVELOPMENT IN AN INDUSTRIAL ENVIRONMENT FORMALIZED SOFTWARE DEVELOPMENT IN AN INDUSTRIAL ENVIRONMENT Otthein Herzog IBM Germany, Dept. 3100 P.O.Box 80 0880 D-7000 STUTTGART, F. R. G. ABSTRACT tn the IBM Boeblingen Laboratory some software was

More information

Getting a Quick Start with RUP

Getting a Quick Start with RUP Getting a Quick Start with RUP By: Doug Rosenberg and Jeff Kantor, ICONIX Software Engineering, Inc. Abstract Many people want the rigor of an industrial-strength process like the RUP but aren't quite

More information

Modeling Systems Using Design Patterns

Modeling Systems Using Design Patterns Modeling Systems Using Design Patterns Jaroslav JAKUBÍK Slovak University of Technology Faculty of Informatics and Information Technologies Ilkovičova 3, 842 16 Bratislava, Slovakia jakubik@fiit.stuba.sk

More information

Transactions on Information and Communications Technologies vol 7, 1994 WIT Press, ISSN

Transactions on Information and Communications Technologies vol 7, 1994 WIT Press,   ISSN Teaching object oriented techniques with IR_Framework: a class library for information retrieval S. Wade, P. Braekevelt School of Computing and Mathematics, University of Huddersfield, UK Abstract This

More information

History of object-oriented approaches

History of object-oriented approaches Prof. Dr. Nizamettin AYDIN naydin@yildiz.edu.tr http://www.yildiz.edu.tr/~naydin Object-Oriented Oriented Systems Analysis and Design with the UML Objectives: Understand the basic characteristics of object-oriented

More information

Lecture 2: Software Engineering (a review)

Lecture 2: Software Engineering (a review) Lecture 2: Software Engineering (a review) Kenneth M. Anderson Object-Oriented Analysis and Design CSCI 6448 - Spring Semester, 2003 Credit where Credit is Due Some material presented in this lecture is

More information

Introduction. Chapter 1. What Is Visual Modeling? The Triangle for Success. The Role of Notation. History of the UML. The Role of Process

Introduction. Chapter 1. What Is Visual Modeling? The Triangle for Success. The Role of Notation. History of the UML. The Role of Process Quatrani_Ch.01.fm Page 1 Friday, October 27, 2000 9:02 AM Chapter 1 Introduction What Is Visual Modeling? The Triangle for Success The Role of Notation History of the UML The Role of Process What Is Iterative

More information

Evaluation of Commercial Web Engineering Processes

Evaluation of Commercial Web Engineering Processes Evaluation of Commercial Web Engineering Processes Andrew McDonald and Ray Welland Department of Computing Science, University of Glasgow, Glasgow, Scotland. G12 8QQ. {andrew, ray}@dcs.gla.ac.uk, http://www.dcs.gla.ac.uk/

More information

Software Design, Modelling and Analysis in UML

Software Design, Modelling and Analysis in UML Software Design, Modelling and Analysis in UML Lecture 02: Semantical Model 2013-10-23 02 2013-10-23 main Prof. Dr. Andreas Podelski, Dr. Bernd Westphal Albert-Ludwigs-Universität Freiburg, Germany Contents

More information

HyperFrame - A Framework for Hypermedia Authoring

HyperFrame - A Framework for Hypermedia Authoring HyperFrame - A Framework for Hypermedia Authoring S. Crespo, M. F. Fontoura, C. J. P. Lucena, D. Schwabe Pontificia Universidade Católica do Rio de Janeiro - Departamento de Informática Universidade do

More information

.NET & Web Services. Mike Lockyer, Gary Griffiths, Briony Oates, Barry Hebbron School of Computing. University of Teesside

.NET & Web Services. Mike Lockyer, Gary Griffiths, Briony Oates, Barry Hebbron School of Computing. University of Teesside .NET & Web Services Mike Lockyer, Gary Griffiths, Briony Oates, Barry Hebbron School of Computing Middlesbrough, TS1 3BA UK m.a.lockyer@tees.ac.uk ABSTRACT In this paper we present our current approach

More information

Review of Basic Software Design Concepts. Fethi Rabhi SENG 2021

Review of Basic Software Design Concepts. Fethi Rabhi SENG 2021 Review of Basic Software Design Concepts Fethi Rabhi SENG 2021 1 Topics The development process Planning Designing Implementing 2 1. The development process How to organise activities related to the creation,

More information

The Bizarre Truth! Automating the Automation. Complicated & Confusing taxonomy of Model Based Testing approach A CONFORMIQ WHITEPAPER

The Bizarre Truth! Automating the Automation. Complicated & Confusing taxonomy of Model Based Testing approach A CONFORMIQ WHITEPAPER The Bizarre Truth! Complicated & Confusing taxonomy of Model Based Testing approach A CONFORMIQ WHITEPAPER By Kimmo Nupponen 1 TABLE OF CONTENTS 1. The context Introduction 2. The approach Know the difference

More information

1 OBJECT-ORIENTED ANALYSIS

1 OBJECT-ORIENTED ANALYSIS UML and Patterns.book Page 3 Sunday, August 9, 200 2:50 PM Chapter OBJECT-ORIENTED ANALYSIS AND DESIGN The shift of focus (to patterns) will have a profound and enduring effect on the way we write programs.

More information

Integrating Systems and Software Engineering Concepts in AP-233

Integrating Systems and Software Engineering Concepts in AP-233 Integrating Systems and Software Engineering Concepts in AP-233 Asmus Pandikow, Erik Herzog, Anders Törne Real-Time Systems Laboratory Linköpings Universitet 581 83 Linköping, Sweden E-mail: {asmpa, erica,

More information

Requirements and Design Overview

Requirements and Design Overview Requirements and Design Overview Robert B. France Colorado State University Robert B. France O-1 Why do we model? Enhance understanding and communication Provide structure for problem solving Furnish abstractions

More information

Lecture 02: Semantical Model

Lecture 02: Semantical Model Software Design, Modelling and Analysis in UML Lecture 02: Semantical Model 2014-10-23 02 2014-10-23 main Prof. Dr. Andreas Podelski, Dr. Bernd Westphal Albert-Ludwigs-Universität Freiburg, Germany Contents

More information

Definition of Information Systems

Definition of Information Systems Information Systems Modeling To provide a foundation for the discussions throughout this book, this chapter begins by defining what is actually meant by the term information system. The focus is on model-driven

More information

Object-Oriented Design

Object-Oriented Design Object-Oriented Design Lecture 14: Design Workflow Department of Computer Engineering Sharif University of Technology 1 UP iterations and workflow Workflows Requirements Analysis Phases Inception Elaboration

More information

Improving System Usability Through the Automation of User's Routine Intentions: an Image Edition Tool Case Study

Improving System Usability Through the Automation of User's Routine Intentions: an Image Edition Tool Case Study Improving System Usability Through the Automation of User's Routine Intentions: an Image Edition Tool Case Study Alejandro C. Frery, André R. G. do A. Leitão, André W. B. Furtado, Fernando da C. A. Neto,

More information

Lecture Notes UML UNIT-II. Subject: OOAD Semester: 8TH Course No: CSE-802

Lecture Notes UML UNIT-II. Subject: OOAD Semester: 8TH Course No: CSE-802 UNIT-II Lecture Notes On UML IMPORTANCE OF MODELING, BRIEF OVERVIEW OF OBJECT MODELING TECHNOLOGY (OMT) BY RAMBAUGH, BOOCH METHODOLOGY, USE CASE DRIVE APPROACH (OOSE) BY JACKOBSON. KHALID AMIN AKHOON 1

More information

Chapter 1: Principles of Programming and Software Engineering

Chapter 1: Principles of Programming and Software Engineering Chapter 1: Principles of Programming and Software Engineering Data Abstraction & Problem Solving with C++ Fifth Edition by Frank M. Carrano Software Engineering and Object-Oriented Design Coding without

More information

Verification and Validation. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1

Verification and Validation. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1 Verification and Validation 1 Objectives To introduce software verification and validation and to discuss the distinction between them To describe the program inspection process and its role in V & V To

More information

Objectives. UML Extension Mechanisms. What is UML? Is the UML enough? UML Extension Mechanisms. Specifications. By Jasmine Farhad

Objectives. UML Extension Mechanisms. What is UML? Is the UML enough? UML Extension Mechanisms. Specifications. By Jasmine Farhad UML Extension Mechanisms By Jasmine Farhad j.farhad@cs.ucl.ac.uk Objectives Briefly describe the UML Introduce the UML Extension Mechanisms: Specifications Common Divisions Adornments Extensibility Mechanism(we

More information

Software Development Methodologies

Software Development Methodologies Software Development Methodologies Lecturer: Raman Ramsin Lecture 8 Agile Methodologies: XP 1 extreme Programming (XP) Developed by Beck in 1996. The first authentic XP book appeared in 1999, with a revised

More information

Object Oriented Programming

Object Oriented Programming Binnur Kurt kurt@ce.itu.edu.tr Istanbul Technical University Computer Engineering Department 1 Version 0.1.2 About the Lecturer BSc İTÜ, Computer Engineering Department, 1995 MSc İTÜ, Computer Engineering

More information

Managing Change and Complexity

Managing Change and Complexity Managing Change and Complexity The reality of software development Overview Some more Philosophy Reality, representations and descriptions Some more history Managing complexity Managing change Some more

More information

Software Development Methodologies

Software Development Methodologies Software Development Methodologies Lecturer: Raman Ramsin Lecture 3 Seminal Object-Oriented Methodologies: A Feature-Focused Review (Part 1) 1 Coad-Yourdon Two-phase introduction: Object-Oriented Analysis

More information

An Approach to Software Component Specification

An Approach to Software Component Specification Page 1 of 5 An Approach to Software Component Specification Jun Han Peninsula School of Computing and Information Technology Monash University, Melbourne, Australia Abstract. Current models for software

More information

Sample Exam Syllabus

Sample Exam Syllabus ISTQB Foundation Level 2011 Syllabus Version 2.9 Release Date: December 16th, 2017. Version.2.9 Page 1 of 46 Dec 16th, 2017 Copyright 2017 (hereinafter called ISTQB ). All rights reserved. The authors

More information

MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION (Autonomous) (ISO/IEC Certified)

MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION (Autonomous) (ISO/IEC Certified) Important Instructions to examiners: 1) The answers should be examined by key words and not as word-to-word as given in the model answer scheme. 2) The model answer and the answer written by candidate

More information

Seite 1. "Formal specifications may become for software engineers what, say, differential equations are for engineers of other fields.

Seite 1. Formal specifications may become for software engineers what, say, differential equations are for engineers of other fields. Formal Specification of Software Systems Heinrich Hußmann TU Dresden A Comparison "Formal specifications may become for software engineers what, say, differential equations are for engineers of other fields."

More information

Quality Software Requirements By J. Chris Gibson

Quality Software Requirements By J. Chris Gibson Quality Software Requirements By J. Chris Gibson The information contained within this document has been gathered from a variety of sources and practices observed by the development team at Protera Software

More information

UML and the Cost of Defects

UML and the Cost of Defects UML and the of s Stephen J Mellor stephen_mellor@mentor.com It is common knowledge that software defects, especially in embedded systems, are expensive to repair; less well appreciated is just how very

More information

CSC Advanced Object Oriented Programming, Spring Overview

CSC Advanced Object Oriented Programming, Spring Overview CSC 520 - Advanced Object Oriented Programming, Spring 2018 Overview Brief History 1960: Simula first object oriented language developed by researchers at the Norwegian Computing Center. 1970: Alan Kay

More information

Distributed Systems Programming (F21DS1) Formal Verification

Distributed Systems Programming (F21DS1) Formal Verification Distributed Systems Programming (F21DS1) Formal Verification Andrew Ireland Department of Computer Science School of Mathematical and Computer Sciences Heriot-Watt University Edinburgh Overview Focus on

More information

Slides copyright 1996, 2001, 2005, 2009, 2014 by Roger S. Pressman. For non-profit educational use only

Slides copyright 1996, 2001, 2005, 2009, 2014 by Roger S. Pressman. For non-profit educational use only Chapter 16 Pattern-Based Design Slide Set to accompany Software Engineering: A Practitioner s Approach, 8/e by Roger S. Pressman and Bruce R. Maxim Slides copyright 1996, 2001, 2005, 2009, 2014 by Roger

More information

Describing Computer Languages

Describing Computer Languages Markus Scheidgen Describing Computer Languages Meta-languages to describe languages, and meta-tools to automatically create language tools Doctoral Thesis August 10, 2008 Humboldt-Universität zu Berlin

More information

SDMX self-learning package No. 5 Student book. Metadata Structure Definition

SDMX self-learning package No. 5 Student book. Metadata Structure Definition No. 5 Student book Metadata Structure Definition Produced by Eurostat, Directorate B: Statistical Methodologies and Tools Unit B-5: Statistical Information Technologies Last update of content December

More information

Model Driven Engineering (MDE)

Model Driven Engineering (MDE) Model Driven Engineering (MDE) Yngve Lamo 1 1 Faculty of Engineering, Bergen University College, Norway 26 April 2011 Ålesund Outline Background Software Engineering History, SE Model Driven Engineering

More information

Object-Oriented Programming Using C++ (Introduction To Programming) PDF

Object-Oriented Programming Using C++ (Introduction To Programming) PDF Object-Oriented Programming Using C++ (Introduction To Programming) PDF Using object-oriented terminology from the start, Object-Oriented Programming Using C++, Fourth Edition, will provide readers with

More information

Chapter 12 (revised by JAS)

Chapter 12 (revised by JAS) Chapter 12 (revised by JAS) Pattern-Based Design Slide Set to accompany Software Engineering: A Practitionerʼs Approach, 7/e by Roger S. Pressman Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman

More information

(p t y) lt d. 1995/04149/07. Course List 2018

(p t y) lt d. 1995/04149/07. Course List 2018 JAVA Java Programming Java is one of the most popular programming languages in the world, and is used by thousands of companies. This course will teach you the fundamentals of the Java language, so that

More information

The TOBIAS test generator and its adaptation to some ASE challenges Position paper for the ASE Irvine Workshop

The TOBIAS test generator and its adaptation to some ASE challenges Position paper for the ASE Irvine Workshop The test generator and its adaptation to some ASE challenges Position paper for the ASE Irvine Workshop Y. Ledru Laboratoire Logiciels Systèmes Réseaux/IMAG BP 72, F-38402 Saint-Martin-d Hères CEDEX, FRANCE

More information

Object-Oriented Systems Development: Using the Unified Modeling Language

Object-Oriented Systems Development: Using the Unified Modeling Language Object-Oriented Systems Development: Using the Unified Modeling Language Chapter 4: Object-Oriented Methodologies Goals Object-Oriented Methodologies The Rumbaugh et al. OMT The Booch methodology Jacobson's

More information

OCL Support in MOF Repositories

OCL Support in MOF Repositories OCL Support in MOF Repositories Joachim Hoessler, Michael Soden Department of Computer Science Technical University Berlin hoessler@cs.tu-berlin.de, soden@cs.tu-berlin.de Abstract From metamodels that

More information

USE CASE BASED REQUIREMENTS VERIFICATION

USE CASE BASED REQUIREMENTS VERIFICATION USE CASE BASED REQUIREMENTS VERIFICATION Verifying the consistency between use cases and assertions Stéphane S. Somé, Divya K. Nair School of Information Technology and Engineering (SITE), University of

More information

INTERACTION TEMPLATES FOR CONSTRUCTING USER INTERFACES FROM TASK MODELS

INTERACTION TEMPLATES FOR CONSTRUCTING USER INTERFACES FROM TASK MODELS Chapter 1 INTERACTION TEMPLATES FOR CONSTRUCTING USER INTERFACES FROM TASK MODELS David Paquette and Kevin A. Schneider Department of Computer Science, University of Saskatchewan, Saskatoon, SK S7N 5A9,

More information

Automatized Generating of GUIs for Domain-Specific Languages

Automatized Generating of GUIs for Domain-Specific Languages Automatized Generating of GUIs for Domain-Specific Languages Michaela Bačíková, Dominik Lakatoš, and Milan Nosáľ Technical University of Košice, Letná 9, 04200 Košice, Slovakia, (michaela.bacikova, dominik.lakatos,

More information

Integration With the Business Modeler

Integration With the Business Modeler Decision Framework, J. Duggan Research Note 11 September 2003 Evaluating OOA&D Functionality Criteria Looking at nine criteria will help you evaluate the functionality of object-oriented analysis and design

More information

UML data models from an ORM perspective: Part 4

UML data models from an ORM perspective: Part 4 data models from an ORM perspective: Part 4 by Dr. Terry Halpin Director of Database Strategy, Visio Corporation This article first appeared in the August 1998 issue of the Journal of Conceptual Modeling,

More information

Executive Summary. Round Trip Engineering of Space Systems. Change Log. Executive Summary. Visas

Executive Summary. Round Trip Engineering of Space Systems. Change Log. Executive Summary. Visas Reference: egos-stu-rts-rp-1002 Page 1/7 Authors: Andrey Sadovykh (SOFTEAM) Contributors: Tom Ritter, Andreas Hoffmann, Jürgen Großmann (FHG), Alexander Vankov, Oleg Estekhin (GTI6) Visas Surname - Name

More information

Ghassan Samara Internet Technology Department Zarqa University, Jordan.

Ghassan Samara Internet Technology Department Zarqa University, Jordan. World of Computer Science and Information Technology Journal (WCSIT) ISSN: 2221-0741 Vol. 7, No. 2, 10-19, 2017 A Practical Approach for Detecting Logical Error in Object Oriented Environment Ghassan Samara

More information

FACETs. Technical Report 05/19/2010

FACETs. Technical Report 05/19/2010 F3 FACETs Technical Report 05/19/2010 PROJECT OVERVIEW... 4 BASIC REQUIREMENTS... 4 CONSTRAINTS... 5 DEVELOPMENT PROCESS... 5 PLANNED/ACTUAL SCHEDULE... 6 SYSTEM DESIGN... 6 PRODUCT AND PROCESS METRICS...

More information

DITA for Enterprise Business Documents Sub-committee Proposal Background Why an Enterprise Business Documents Sub committee

DITA for Enterprise Business Documents Sub-committee Proposal Background Why an Enterprise Business Documents Sub committee DITA for Enterprise Business Documents Sub-committee Proposal Background Why an Enterprise Business Documents Sub committee Documents initiate and record business change. It is easy to map some business

More information

The ITIL v.3. Foundation Examination

The ITIL v.3. Foundation Examination The ITIL v.3. Foundation Examination ITIL v. 3 Foundation Examination: Sample Paper 4, version 3.0 Multiple Choice Instructions 1. All 40 questions should be attempted. 2. There are no trick questions.

More information

Future Directions for SysML v2 INCOSE IW MBSE Workshop January 28, 2017

Future Directions for SysML v2 INCOSE IW MBSE Workshop January 28, 2017 Future Directions for SysML v2 INCOSE IW MBSE Workshop January 28, 2017 Sanford Friedenthal safriedenthal@gmail.com 1/30/2017 Agenda Background System Modeling Environment (SME) SysML v2 Requirements Approach

More information

Index. Add Diagram > Sequence Diagram command,

Index. Add Diagram > Sequence Diagram command, Quatrani.book Page 183 Monday, May 8, 2006 11:56 AM Index A abstraction, 3 actions completing before processing, 54 55 data flowing through, 53 passing control between, 51 performing, 155 157 as round-cornered

More information

FormStream a Workflow Prototyping Tool for Classroom Use

FormStream a Workflow Prototyping Tool for Classroom Use FormStream a Workflow Prototyping Tool for Classroom Use Paul Juell and Benjamin Dischinger Department of Computer Science North Dakota State University Computer Science NDSU Fargo, ND 58105 paul.juell@ndsu.edu

More information

Design Engineering. Dr. Marouane Kessentini Department of Computer Science

Design Engineering. Dr. Marouane Kessentini Department of Computer Science Design Engineering Dr. Marouane Kessentini Department of Computer Science 1 Design Starts mostly from/with requirements (evolving mostly from functionalities and other non functional characteristics) How

More information

UNIT I. 3. Write a short notes on process view of 4+1 architecture. 4. Why is object-oriented approach superior to procedural approach?

UNIT I. 3. Write a short notes on process view of 4+1 architecture. 4. Why is object-oriented approach superior to procedural approach? Department: Information Technology Questions Bank Class: B.E. (I.T) Prof. Bhujbal Dnyaneshwar K. Subject: Object Oriented Modeling & Design dnyanesh.bhujbal11@gmail.com ------------------------------------------------------------------------------------------------------------

More information

Outline of Unified Process

Outline of Unified Process Outline of Unified Process Koichiro OCHIMIZU School of Information Science JAIST Schedule(3/3) March 12 13:00 Unified Process and COMET 14:30 Case Study of Elevator Control System (problem definition,

More information

arxiv: v1 [cs.se] 17 Aug 2016

arxiv: v1 [cs.se] 17 Aug 2016 Introduction to the Case Management Model and Notation (CMMN) arxiv:1608.05011v1 [cs.se] 17 Aug 2016 Mike A. Marin University of South Africa IBM Analytics Group mmarin@acm.org August 18, 2016 Abstract

More information

Practical Object-Oriented Design in Ruby

Practical Object-Oriented Design in Ruby Practical Object-Oriented Design in Ruby Anyone that has done a decent amount of programming in Ruby is bound hear about the book Practical Object-Oriented Design in Ruby [1] (http://www.poodr.com/) by

More information

Selection of UML Models for Test Case Generation: A Discussion on Techniques to Generate Test Cases

Selection of UML Models for Test Case Generation: A Discussion on Techniques to Generate Test Cases St. Cloud State University therepository at St. Cloud State Culminating Projects in Computer Science and Information Technology Department of Computer Science and Information Technology 6-2018 Selection

More information

Available online at ScienceDirect. Procedia Computer Science 56 (2015 )

Available online at  ScienceDirect. Procedia Computer Science 56 (2015 ) Available online at www.sciencedirect.com ScienceDirect Procedia Computer Science 56 (2015 ) 612 617 International Workshop on the Use of Formal Methods in Future Communication Networks (UFMFCN 2015) A

More information

Index. business modeling syntax 181 business process modeling 57 business rule 40

Index. business modeling syntax 181 business process modeling 57 business rule 40 OCL.book Page 203 Tuesday, July 22, 2003 9:48 PM Index Symbols OclAny, of 167 = OclAny, of 167 @pre 34, 86, 155 ^ 34, 156 ^^ 157 A abstract syntax 93 accumulator 153 action in statechart 56 activity

More information

Course "Softwaretechnik" Book Chapter 2 Modeling with UML

Course Softwaretechnik Book Chapter 2 Modeling with UML Course "Softwaretechnik" Book Chapter 2 Modeling with UML Lutz Prechelt, Bernd Bruegge, Allen H. Dutoit Freie Universität Berlin, Institut für Informatik http://www.inf.fu-berlin.de/inst/ag-se/ Modeling,

More information

Unified Modeling Language (UML)

Unified Modeling Language (UML) Unified Modeling Language (UML) Troy Mockenhaupt Chi-Hang ( Alex) Lin Pejman ( PJ ) Yedidsion Overview Definition History Behavior Diagrams Interaction Diagrams Structural Diagrams Tools Effect on Software

More information

Software Engineering with Objects and Components 1 Overview

Software Engineering with Objects and Components 1 Overview Software Engineering with Objects and Components 1 Overview Stuart Anderson Room 1610 Tel: 0131 650 5191 Email: soa@inf.ed.ac.uk Note 1 0-0 Administration Course Web Page please read it it is the main

More information

Visualizing Verification. Adrian A. Marsh April 2004

Visualizing Verification. Adrian A. Marsh April 2004 Visualizing Verification Adrian A. Marsh April 2004 Abstract This paper proposes extending UML modeling to system verification. Changing the utilization of the UML diagrams will increase the quality of

More information

Software Engineering from a

Software Engineering from a Software Engineering from a modeling perspective Robert B. France Dept. of Computer Science Colorado State University USA france@cs.colostate.edu Softwaredevelopment problems Little or no prior planning

More information

Oral Questions. Unit-1 Concepts. Oral Question/Assignment/Gate Question with Answer

Oral Questions. Unit-1 Concepts. Oral Question/Assignment/Gate Question with Answer Unit-1 Concepts Oral Question/Assignment/Gate Question with Answer The Meta-Object Facility (MOF) is an Object Management Group (OMG) standard for model-driven engineering Object Management Group (OMG)

More information

CSC 330 Object Oriented Software Design. Software Analysis Phase

CSC 330 Object Oriented Software Design. Software Analysis Phase CSC 330 Object Oriented Software Design Software Analysis Phase 1 Overview Object-oriented analysis Use-case modeling Class modeling Dynamic modeling Testing during the object-oriented analysis phase CASE

More information

SRM ARTS AND SCIENCE COLLEGE SRM NAGAR, KATTANKULATHUR

SRM ARTS AND SCIENCE COLLEGE SRM NAGAR, KATTANKULATHUR SRM ARTS AND SCIENCE COLLEGE SRM NAGAR, KATTANKULATHUR 603203 DEPARTMENT OF COMPUTER SCIENCE & APPLICATIONS LESSON PLAN (2017-2018) Course / Branch : BCA Total Hours : 45 Subject Name : OBJECT ORIENTED

More information

02291: System Integration

02291: System Integration 02291: System Integration Hubert Baumeister hub@imm.dtu.dk Spring 2012 Contents 1 General Information 1 2 Overview 3 3 Introduction to UML 11 4 Summary 16 1 General Information System Integration Type

More information

A Top-Down Visual Approach to GUI development

A Top-Down Visual Approach to GUI development A Top-Down Visual Approach to GUI development ROSANNA CASSINO, GENNY TORTORA, MAURIZIO TUCCI, GIULIANA VITIELLO Dipartimento di Matematica e Informatica Università di Salerno Via Ponte don Melillo 84084

More information

Software Development. Modular Design and Algorithm Analysis

Software Development. Modular Design and Algorithm Analysis Software Development Modular Design and Algorithm Analysis Functional Decomposition Functional Decomposition in computer science, also known as factoring, refers to the process by which a complex problem

More information

Information systems modelling UML and service description languages

Information systems modelling UML and service description languages Internet Engineering Tomasz Babczyński, Zofia Kruczkiewicz Tomasz Kubik Information systems modelling UML and service description languages Introduction INFORMATION SYSTEMS MODELLING, UML AND SERVICE DESCRIPTION

More information

Newly-Created, Work-in-Progress (WIP), Approval Cycle, Approved or Copied-from-Previously-Approved, Work-in-Progress (WIP), Approval Cycle, Approved

Newly-Created, Work-in-Progress (WIP), Approval Cycle, Approved or Copied-from-Previously-Approved, Work-in-Progress (WIP), Approval Cycle, Approved A New Approach to Enterprise Data Organization A Cuboid Enterprises are generally overwhelmed with data, making the ability to store, process, analyze, interpret, consume, and act upon that data a primary

More information

Enterprise Architect Training Courses

Enterprise Architect Training Courses On-site training from as little as 135 per delegate per day! Enterprise Architect Training Courses Tassc trainers are expert practitioners in Enterprise Architect with over 10 years experience in object

More information

Rose/Architect: a tool to visualize architecture

Rose/Architect: a tool to visualize architecture Rose/Architect: a tool to visualize architecture Alexander Egyed University of Southern California Center for Software Engineering Los Angeles, CA 90089-0781, USA aegyed@sunset.usc.edu Philippe B. Kruchten

More information

CSCU9T4: Managing Information

CSCU9T4: Managing Information CSCU9T4: Managing Information CSCU9T4 Spring 2016 1 The Module Module co-ordinator: Dr Gabriela Ochoa Lectures by: Prof Leslie Smith (l.s.smith@cs.stir.ac.uk) and Dr Nadarajen Veerapen (nve@cs.stir.ac.uk)

More information

Software Design Using CRC Cards

Software Design Using CRC Cards By Harold Halbleib, Product Manager, Excel Software. Software Design Using CRC Cards Many notations, methods and books have been published in recent years regarding analysis and design of object-oriented

More information