Jacobsen, I. (1992). Object-Oriented Software Engineering. New York: Addison-Wesley. Jeries, R. (1999, March/April). Extreme testing. Software Testing & Quality Engineering , 23-26.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....examined. Key words: UML, OCL, tool, validation, case study, testing 1 Introduction The Unified Modeling Language (UML) 7] is regarded today as a very important standard for the development of software systems. UML originated from its main predecessor approaches Booch [3] OMT [11] and OOSE [6]. It is a graphical modeling language supporting many phases in the software development cycle by o#ering diagrams and language features meeting the special needs in respective phases. Many commercial tools for UML are available. The Object Constraint Language (OCL) 7,12] is part of standard UML, ....

I. Jacobsen, M. Christerson, P. Jonsson, and G. G. Overgaard. Object-Oriented Software Engineering. Addison-Wesley, 1992.

....development processes, and business process design. We then discuss related work in section 7, and finally present our conclusions. 2. BACKGROUND 2. 1 Use Cases Jacobson defines a use case in his 1992 book as a behav iorally related sequence of transactions in a dialogue with the system [17]. A more recent definition for the Rational Unified Process shows little real change, saying a use case is a description of a set or sequence of actions, including variants, that a system performs that yields an observable result of value to a particular actor [16] The general idea of a use ....

....the system as a black box , with an explicit boundary, describing the behavior of the system by essential use case responsibilities. We can regard the system as a single system object, with a set of responsibilities like any object, and an implementation not yet under consideration. Jacobson [17] proposes a similar idea, but takes it in a different direction. With essential use cases, we can use the responsibilities to help determine the boundary of the system. If the system is like a single object, then the use cases are like methods of this object. They allow access to the system ....

[Article contains additional citation context not shown here]

Ivar Jacobson, Mahnus Christerson, Patrik Jonsson, and Gunnar Overgaard. Object-Oriented Software Engineering. Addison-Wesley, 1992.

....to affect the Knowledge Life Cycle or one of its components or outcomes. The result of value, the goal of a task, is an effect of the above sort that the agent expects the system to produce. Some KM task patterns, such as sequences of interaction with a computer network (often called use cases [5]) are performed on the physical world, and the response of the physical world to the agent, in the form of the computer s response, is determined by cause and effect. But many more KM task patterns, such as hiring new knowledge workers, are social in character, involve working and collaborating ....

....are external to the information system. Instead, they are part of the organization, the knowledge life cycle, and the KM processes that they act upon, For these reason it would be inappropriate to refer to KM task patterns, in general, as use cases, as that term is used in object technology [5] and specifically in the Unified Modeling Language (UML) 6] Most KM task patterns are different from computer use cases, in that they don t have determinate responses, and in that the agents performing them are part of the process they are influencing. Action and effect are not determined ....

[Article contains additional citation context not shown here]

Ivar Jacobson, Object-oriented Software Engineering (Reading, MA: AddisonWesley, 1998).

....of software evolution is not intended as a comprehensive method for developing object oriented systems. Our method contains important new features and it is intended to be used in conjunction with comprehensive software development methods, such as the Objectory Method by Ivar Jacobson [JCJ O92] We assume that we have derived a schema, e.g. from the use cases in the Objectory method, and that we need to provide application specific functionality, e.g. to implement a use case. The common approach today is to define methods and to attach them to specific classes. Our experience with ....

Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard. Object-Oriented Software Engineering. Addison-Wesley, 1992.

....prose and formal notation (in the form of assertions) 8] The preconditions are often formal and complete, whereas the formal parts of the postconditions are typically partial, if present at all. 4.2. Related work The use of examples in documentation is an old and obvious idea. Today, use cases [7] are probably the best known technique for software documentation based on examples. While use cases are usually informal and not executable, scenarios can be made executable, as research on SCR requirements specifications has shown [9] Our test cases can be thought of as executable API use ....

I. Jacobsen. Object-Oriented Software Engineering. Addison-Wesley, New York, 1992.

....computer systems must deliver a certain quality of service (QoS) to its users. By QoS, we refer to non functional properties such as performance, reliability, availability, and security. Although the delivered QoS is an essential aspect of a computer system, traditional design methods, such as [2, 11, 1, 13, 4], do not incorporate QoS considerations into the design process. We strongly believe that, in order to build systems that deliver their intended QoS, it is essential to systematically take QoS into account at design time, and not as an afterthought during implementation. TradingStation ....

....offers first class citizens from a design language point of view. Finally, we believe the example shows that QML is suitable to support designers in involving QoS considerations in the design phase. 7. Related Work Common object oriented analysis and design languages, such as UML [2] Objectory [13], Booch notation [1] and OMT [11] generally lack concepts and constructs for QoS specification. In some cases, they have limited support to deal with temporal aspects or call semantics [1] Interface definition languages, such as OMG IDL [17] specify functional properties and lack any notion ....

Ivar Jacobson, Magnus Christerson and Persson. ObjectOriented Software Engineering. Addison-Wesley, 1992.

....implementation, testing, and maintenance. The first step in analysis is acquiring an understanding of the domain for which the software is being developed. However, typical research into methods to facilitate reuse have focused on the reuse of components at the code and implementation level [16][35]. These components include class or function definitions and utility routines or middleware. Less emphasis has been placed on the reuse of elements tied domain requirements. These elements are based on the ontology, behaviors, and configuration rules describing the domain. The information in ....

Ivar Jacobson, "Object-Oriented Software Engineering," Workingham, England: Addison-Wesley, 1992.

....To the contrary, as system become more complex, formal methods are indispensable. However, they have to be complemented with a sound understanding of the current work practice and the possible future use of the system from the end users perspective. The use case methodology by Jacobsen et al. [15]) is an example for the incorporation of the end user s perspective into system design. Use cases are descriptions of the interaction of an actor external to the system (usually a human user) and the system itself. A use case thus encapsulates one specific way of using the system by using some ....

Jacobsen, I., Christerson, M., Jonsson, P., and vergaard, G., Object-Oriented Software Engineering. A Use Case Driven Approach: ACM Press, 1992.

.... the conceptual schema [19] Different techniques for data modeling, e.g. extended) entity relationship modeling [5, 11, 32, 13] mathematical models [6] irreducible data models [34] static models with semantic hierarchy [20] dynamic models with semantic hierarchy [27] and object oriented ones [1, 4, 25, 30, 39], were proposed in the past. All techniques model the static aspects of a system, some of them model the properties and the behaviour of the entities, too, settled in the Universe of Discourse (UoD) Function models describe how output values are derived from input values visualized as flow of ....

....Methods for conceptual modeling have to offer concepts and techniques for modeling various kinds of systems [8] In addition a schema for the engineering process in general, augmented by design rules, has to be supplied. Usually conceptual modeling is ruled by a general design idea; Jacobsen [25] divides traditional ones, characterized as function data methods, and objectoriented methods. In the following sections we introduce NetCASE, a method which can neither be characterized as a function data method nor as a objectoriented one. NetCASE attempts to unite advantages of both paradigms. ....

[Article contains additional citation context not shown here]

I. Jacobsen, Object-Oriented Software Engineering, Addison Wesley, 1992.

....to the model building, a single performance engineering approach can be applied with any software development methodology. The traces provide independence from the language used to express a software system design. For example, an alternative source of angio traces could be embellished Use Case [40] investigations. Provided the traces can be generated, the technique can be used during any phase of a system s lifecycle including analysis, design, testing, operation, and reengineering. By generating traces and using an appropriate performance model, the technique can be adapted to virtually ....

Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard. Object-Oriented Software Engineering. Addison-Wesley Publishing, New York, 1992.

....implementation. Finally, in section 8 conclusions are presented. 2 Related Work and Forces Several approaches to the development of concurrent applications propose the separation of application functionalities part from the concurrent part. These approaches are based on object oriented methods [Jacobson 92] enrichment of existing languages with new keywords and annotations [Caromel 93, Meyer 93, Lohr 93] class hierarchy and platform mechanisms [Liskov 88, Parrington 88, McCue 92, Fazzolare 93] and definition of new languages and models [Lopes 94, Ciancarini 95, Baquero 95] Most of these ....

....[Liskov 88, Parrington 88, McCue 92, Fazzolare 93] and definition of new languages and models [Lopes 94, Ciancarini 95, Baquero 95] Most of these approaches enforce the development of a sequential application first, which should be enriched with concurrency afterwards. For instance in [Jacobson 92] a use case model describing application functionalities from the users perspective, does not consider concurrency issues at this stage. Basically, we follow this approach. Concurrency can be decoupled in concurrency generation and concurrency control. The former manages creation, execution and ....

Ivar Jacobson. Object-Oriented Software Engineering. Addison-Wesley, 1992.

.... integration control and version control ffl regular testing and evaluation, and short communication paths ffl management of reusable components and standards As the choice of adequate software engineering methodologies is abundant (and somehow an individual process) we only mention Objectory [JCJO92] as our choice for early development phases. Object orientation, not only for the analysis which captures the intuitive organization of the application, but also for design and implementation, offer the concepts crucial for the construction of an evolutionary prototype (modularization, ....

Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard. ObjectOriented Software Engineering. Addison-Wesley, 1992.

....middle ground between usability and formalism. 2.2.1 Informal System Specification Methodologies First Generation Methodologies. The leading first generation informal and semi informal system methodologies include Booch [15, 16] Coad Yourdon [35, 36] Martin Odell [118, 119] OOSE Objectory [93, 94], Rumbaugh [142, 143] Shlaer Mellor [148, 149] Syntropy [39] and Wirfs Brock [174] These methodologies focused primarily on building small to medium scale (up to hundreds of classes) object oriented systems. Some are not integrally tied to the object oriented paradigm, they are either ....

....Each of these individuals brought their own perspective and modeling language and process to the table. Booch developed the previously mentioned Booch method [15] Rumbaugh s language is called the Object Modeling Technique (OMT) 143] and Jacobson s language and process are called OOSE Objectory [93]. Additionally, several other companies, individuals, and methods influenced the development of UML. One of the most influential methods is called Catalysis, and is considered one of the leadingedge methods available today 1 . Finally, there exist some new methods that are outside the ....

Ivar Jacobson, M. Christerson, P. Jonsson, and G. Overgaard. Object-Oriented Software Engineering. Addison-Wesley Publishing Company, 1992.

....between classes; and ffl inheritance diagrams that depict the class inheritance hierarchy. Implementation is expected to transform the analysis and design results to actual running code. 6.4 General Comments Many other object oriented methodologies exist. Among others, Coad [14] Jacobson [15], Schultz [17] WirfsBrock [20] and Buhr [13] have their flavors of the OOM. However, like the three methodologies described above, these methodologies target the analysis phase of a project and barely touch the design. The primary products are documents that capture the analysis and design ....

Ivar Jacobson et.al. Object-Oriented Software Engineering, Addison-Wesley, ACM Press, 1992.

.... multiple objects functional model: describes behavior of specific functions (intra object dynamics) intra object transformation behavior at the level of algorithms These three levels provide a robust modeling framework for a variety of models of object oriented design, as pointed out by Jacobson [Ja]. They reflect the fact that nouns provide a more direct and more expressive model of the real world than verbs and the further fact that nouns are modeled computationally by the patterns of actions (verbs) that they support. Nouns whose behavior is expressed by patterns of observable actions are ....

....of object functionality. Class based inheritance is less scalable than multiple interfaces as an organizing principle for interfaces, both because complex objects are naturally modeled by multiple interfaces and because hierarchies are too restrictive a structuring principle. Use case models [Ja], as well as COM OLE, elevate collections of interfaces that share a state into a primary structuring principle of software design. dynamic invocation IDL stubs ORB interface static IDL skeleton dynamic skeleton object adapter Client Figure 10: CORBA Interoperability Architecture Object Request ....

Ivar Jacobson, Object-Oriented Software Engineering, Addison-Wesley/ACM Press, 1991.

....navigation by users are given by SNNs. DPNs possibly contain user interaction, too, but they are basically intended for data access. SNNs are set up for a better distinction and to expose status. Compared to other approaches they are related to use cases [Booch, 1994] and interaction diagrams [Jacobsen, 1992]. SNNs are kept pretty simple in order to stress the main concepts and to avoid misuse. They are founded on condition event nets (ce nets) Reisig, 1982] a subclass of PrT nets. Thus, places and edges are marked with one anonymous token only. Directed by control flow and restricted by ....

Ivar Jacobsen. Object-Oriented Software Engineering. AddisonWesley, 1992.

....development of heterogeneous applications (heterogeneity of policies and mechanisms) The mechanism level of abstraction can be implemented over heterogeneous languages and machines. Our approach follows the object oriented analysis and design paradigm. Other object oriented approaches, e.g. [5, 6, 7, 8], have as yet not addressed distribution issues in depth. The rest of this paper is structured as follows. Distribution concerns are described in section 2. In section 3 abstraction levels are introduced. The development process is described in section 4 while section 5 describes the integration ....

....is depicted in figure 3. durability concurrency robustness X X X X X X X replication naming concurrency failure configuration communication fragmentation X X X X X X X X X X X X concerns stages distribution logical distribution physical X Figure 3: Stages and concerns. Analysis employ use cases [6], describing user requirements enriched with model descriptions, e.g. the degree of interference between use cases [13] All other stages may use an object oriented notation (as in [8] for instance) As expected, models are described in the analysis, while policies and abstract mechanisms are ....

[Article contains additional citation context not shown here]

Ivar Jacobson. Object-Oriented Software Engineering. Addison-Wesley, 1992.

....recognizers trained by Tony Robinson et al. 12] require many days of processing power for training. 4.1. Object Oriented Programming Object oriented programming has many advantages over traditional programming techniques primarily increased maintainability, reusability, and modifiability [8]. However, in the interests of efficiency we need to be careful with the granularity at which we define our objects. The extreme case is if we consider each weight to be a separate object. Typically this incurs a major performance hit. A level which we find appropriate is the node level for ....

....of such tools. 6. Software Design The design of efficient, maintainable, and reusable object oriented software is difficult and is not the topic of this paper. An excellent source of instruction on the design of reusable object oriented software is [7] Classics in software engineering include [8, 3, 5]. 7. Summary In summary, we have concentrated on correctness, efficiency, maintainability, and extendability. The following recommendations have been found to be helpful: 1. Avoid duplication. For maintainability, but primarily for correctness. 2. Use object oriented design to aid reuse of ....

Ivar Jacobsen, Magnus Christerson, Patrik Jonsson, and G.G. Overgaard. Object-Oriented Software Engineering. AddisonWesley, 1992.

....and hence makes it a principle target for configuration management and software quality assurance. Important prerequisites of evolutionary prototyping are: 1. Sophisticated software engineering methodologies to facilitate a comprehensible and thorough requirements specification (e.g. Use Cases [JCJO92] and to assist the definition of a solid, but extensible system design (e.g. OMT [RBP 91] 2. Object orientation not only for the development methodology which captures the intuitive organization of the embedded knowledge, but also for the implementation. Object orientation offers the ....

Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard. ObjectOriented Software Engineering. Addison-Wesley, 1992.

....developers can easily learn and apply. The core concepts can be combined and extended so that expert object modelers can define large and complex systems across a wide range of domains. The UML effort [BJR97c] is an offspring of the object oriented development methods OMT [RBP 91] OOSE [JCJO92] and OOA OOD [Boo94] UML comprises a number of diagram forms used to describe particular aspects of software artifacts: the diagram forms can be divided depending on whether they are intended to describe structural or behavioral aspects. One particularly important diagram form concerning ....

Ivar Jacobsen, Magnus Christerson, Patrik Jonsson, and G. G. Overgaard. Object-Oriented Software Engineering. Addison-Wesley, 1992.

....engineering is usually dealing with its complexity by investigating the different areas of concern separately. Conceptual models are developed for individual aspects, such as e.g. software process modeling [AM92, BFG93, TDK94] object oriented) specification techniques [Boo91, RBP 91, JCJO92] software architecture [FkNO92, PW92, GAO94] or requirements engineering [Poh92] Focusing on isolated areas of concern can lead to sophisticated theoretical models, and thereby to more insights and deeper understanding about that certain area. But in real life software development projects, ....

Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard. Object-Oriented Software Engineering. Addison-Wesley, 1992.

....development of heterogeneous applications: heterogeneity of policies and mechanisms. The mechanism level of abstraction can be implemented over heterogeneous languages and machines. Our approach follows the object oriented analysis and design paradigm. Other object oriented approaches, e.g. [33, 18, 4, 9], have as yet not addressed distribution issues in depth. The rest of this paper is structured as follows. Distribution concerns are described in section 2. In section 3 abstraction levels are introduced. The development process either centered on concerns or on stages is described in sections 4 ....

....a solution that integrates and optimizes several solutions. The latter integrates solutions such that changes to existing representations are minimal. These controlled changes allow representations to be traceable, i.e. it is possible to trace objects in one representation to objects in another [18]. Furthermore, minimal changes allow for stepwise verification and testing: new inconsistencies and bugs can only be caused by the solution for the current concern. 4.2 Assistant Products During development, predefined components, defined in specification or code, can be used as assistant ....

[Article contains additional citation context not shown here]

Ivar Jacobson. Object-Oriented Software Engineering. Addison-Wesley, 1992.

....developers can easily learn and apply. The core concepts can be combined and extended so that expert object modelers can define large and complex systems across a wide range of domains. The UML effort [BJR97c] is an offspring of the object oriented development methods OMT [RBP 91] OOSE [JCJO92] and OOA OOD [Boo94] UML comprises a number of diagram forms used to describe particular aspects of software artifacts: the diagram forms can be divided depending on whether they are intended to describe structural or behavioral aspects. One particularly important diagram form concerning ....

Ivar Jacobsen, Magnus Christerson, Patrik Jonsson, and G. G. Overgaard. Object-Oriented Software Engineering. Addison-Wesley, 1992.

No context found.

Jacobsen, I. (1992). Object-Oriented Software Engineering. New York: Addison-Wesley. Jeries, R. (1999, March/April). Extreme testing. Software Testing & Quality Engineering , 23-26.

No context found.

Jacobsen, I., Christerson, M., Jonsson, P., and Overgaard, G.G., 1992, Object-Oriented Software Engineering , Addison-Wesley.

No context found.

Ivar Jacobson. Object-Oriented Software Engineering. Addison-Wesley, 1992.

No context found.

I. Jacobsen, M. Christerson, P. Jonsson, and G. Overgaard, Object-Oriented Software Engineering, Addison-Wesley, 1992, ISBN 0-201-54435-0.

No context found.

Ivar Jacobson, Object-Oriented Software Engineering, Addison -Wesley, Wokingham, 1992.

No context found.

Jacobsen I., M. Christerson, P. J. G. Overgaard, Object oriented software engineering, a use case driven approach, Addison-Wesley, 1992.

No context found.

I. Jacobsen, M. Christerson, P. Jonsson, and G. Overgaard, Object-Oriented Software Engineering, Addison-Wesley, 1992, ISBN 0-201-54435-0.

No context found.

Ivar Jacobson, Magnus Christerson, Patrik Jonsson, ObjectOriented Software Engineering, A use Case Driven Approach, Addison-Wesley, 1992

No context found.

Ivar Jacobson, Object-Oriented Software Engineering, Addison -Wesley, Wokingham, 1992.

No context found.

-- Ivar Jacobson, Magnus Christerson, Patrik Jonsson and Gunnar vergaard, Object-Oriented Software Engineering, Addison-Wesley, 1992.

No context found.

Ivar Jacobson, Object-Oriented Software Engineering, Addison -Wesley, Wokingham, 1992.

No context found.

Ivar Jacobson, Magnus Christerson and Persson. ObjectOriented Software Engineering. Addison-Wesley, 1992.

No context found.

Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard. ObjectOriented Software Engineering. Addison-Wesley, 1992. BIBLIOGRAPHY 184

No context found.

Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard. Object-Oriented Software Engineering. Addison-Wesley, Reading, MA, 1992. ISBN 0-201-54335-0.

No context found.

Object-Oriented Software Engineering. A Use Case Driven Approach, Addison Wesley.

No context found.

Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard. Object-Oriented Software Engineering. Addison-Wesley, 1991.

No context found.

Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard. Object-Oriented Software Engineering, A Use Case Driven Approach. AddisonWesley, ACM Press, 2 edition, 1993.

No context found.

Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard. Object-Oriented Software Engineering, A Use Case Driven Approach. AddisonWesley, ACM Press, 2 edition, 1993.

No context found.

Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard. Object-Oriented Software Engineering, A Use Case Driven Approach. Addison-Wesley, ACM Press, 2 edition, 1993.

No context found.

Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard. Object-Oriented Software Engineering, A Use Case Driven Approach. AddisonWesley, ACM Press, 2 edition, 1993.

No context found.

Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard. Object-Oriented Software Engineering, A Use Case Driven Approach. AddisonWesley, ACM Press, 2 edition, 1993.

No context found.

Jacobsen, I., Christerson, M., Jonsson, P., and Overgaard, G.G., 1992, "Object-Oriented Software Engineering ", Addison-Wesley.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC