DOCSLIB.ORG

UML Activity Diagrams and Modeling • Chap 28, 29 of Textbook • Activity Diagram Shows Sequential and Parallel Activities in a Process

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
UML Activity Diagrams and Modeling • Chap 28, 29 of Textbook • Activity Diagram Shows Sequential and Parallel Activities in a Process UML Activity Diagrams and Modeling • Chap 28, 29 of textbook • Activity diagram shows sequential and parallel activities in a process. • Activity diagrams are useful for modeling business processes, workflows and complex algorithms. • UML state diagrams shows interesting events and states of an object. It shows how the object behaves in response to events. A Typical UML Activity diagram Activity diagram • Rich notation to show a sequence of activities including parallel activities • Useful for visualizing business workflows and processes. • Often better that a fully dressed use case for depicting complex activities. • Partitions are useful in seeing multiple parties and parallel actions More UML Activity Diagram notation This defines the sub- activity “deliver order” I could not find the Rake symbol in MagicDraw. Use the word (RAKE) for now. Signals – useful to handle events Activity diagram is useful in depicting very complex processes. The Rake symbol and sub activity is useful for an overall view Specifying Behaviour • Interaction diagrams – show how object behave in particular interactions – do not specify all the possible behaviours of objects • Different notation is needed to summarize the overall behaviour of objects • UML defines statecharts for this purpose State machine diagrams and modeling • Illustrates the interesting events and states of an object. • State independent objects always responds the same way with respect to an event. • A state dependent object reacts differently to events based on their state or mode, determined by the values of some internal variables. • A phone is a state dependent object. • A state machine diagram is useful to depict state dependent objects. State-dependent Behaviour • If an object responds differently to the same stimulus at different times, this is modelled by defining a set of states – an object can be in one state at any time – the state it is in determines how it responds to events detected or messages received – in particular, an event can cause the object to move from one state to another (a transition) A simplified view of a simple CD player • Our CD player has – A place to hold a CD (which may be empty or have a CD) – User interface consisting of – A load button (opening /closing the place to hold CD) – A play button (play a CD – after closing place to hold CD) – A stop button (Stop playing) • This may be modeled by having three states – The machine is “closed”, “open” or “playing” States, Events and Transitions • A simple statechart for a CD player: Statechart Semantics • A statechart defines the behaviour of instances of a given class • An object is in one active state at a time • Events may be received at any time • An event can trigger a transition – a transition from the active state will fire if it is labelled with the event just received • The transition leads to the next active state Initial and final states • Generally we use an initial state (a special state) that the machine is initially in. • When the machine stops it is in a final state (also a special state). When the machine enters the final state it no longer responds to any trigger. Initial and Final States using magicdraw • Model the creation and destruction of objects To put a label on an arrow, just select the label and start typing the label. Non-determinism – avoid using guard • Sometimes there are two transitions with the same event label leaving a state. What if there is no CD in the machine and we press play? Nothing should happen. You may show this as follows: • This is called non-deterministic behaviour – but usually the non-determinism can be removed by adding more information Guard Conditions • Conditions added to events indicate when a transition can fire For conditions, use textbox in magicdraw Actions • Actions are performed when a transition fires Actions are short self- contained processing, written in plain English or pseudo-code, after the transition name with a /. Be brief! For actions, use textbox in magicdraw Entry and exit actions • Entry and exit actions are properties of states – they are performed whenever an object arrives at or leaves the state, respectively For each state there may be an entry condition, and exit condition Activities • Extended operations that take time to complete is shown as an activity. • Activities are performed while the object is in a state • unlike actions, they can be interrupted by new events Completion Transitions • If an activity completes uninterrupted it can trigger a completion transaction – these are transitions without event labels Internal Transitions • Internal transitions do not change state – and so do not execute entry and exit actions Creating a Statechart • It can be hard to identify all necessary states • Statecharts can be developed incrementally – consider individual sequences of events received by an object – these might be specified on interaction diagrams – start with a statechart for one interaction – add states as required by additional interactions Ticket Machine • Consider a ticket machine with two events – select a ticket type – enter a coin • Basic interaction is to select a ticket and then enter coins – model this as a ‘linear’ statechart Refining the Statechart • This can be improved by adding ‘loops’ – the number of coins entered will vary: entry will continue until the ticket is paid for – the whole transaction can be repeated Adding Another Interaction • Suppose the user could also enter a coin before selecting a ticket • A ‘coin’ transition from the ‘Idle’ state is needed to handle this event – this transition can’t go to the ‘Paying for Ticket’ state as the ticket is not yet selected – so a new state ‘Inserting Coins’ is required • The statechart is thus built up step-by-step Adding a Second Interaction • If all coins are entered before ticket selected: Integrating the Interactions • In fact, events can occur in any sequence: Time Events • Suppose the ticket machine times out after 30 seconds – we need to fire a transition that is not triggered by a user-generated event – UML define time events to handle these cases For time events, use textbox in magicdraw Activity States • Activity states defines periods of time when the object is carrying out internal processing – unlike normal activities, these cannot be interrupted by external events – only completion transitions leading from them – useful for simplifying the structure of complex statecharts Returning Change • Use an activity state to calculate change Ticket Machine Statechart A problem to solve A simple digital watch consists of a display showing hors and minutes separated by a flashing colon and provides two buttons (A and B) which enable the display to be updated. a) To add two to the number of hours displayed, the following actions should be performed, where button B increments the hours display: Press A; press B; press B; press A; pressA. Draw a simple statechart showing precisely this sequence of events. b) In the above interactions, the hours displayed could be incremented by any required number and the whole interaction could be repeated as often as required. Redraw the statechart to incorporate these generalizations. c) To increment the number of minutes displayed by the watch, button A can be pressed twice, followed by repeated presses of button B, each of which increases the minutes displayed by 1. Draw a complete statechart for the watch, incorporating updates to both hours and minutes displayed.. Give the states in your statechart meaningful names and add appropriate actions to any action to any transition labelled ‘press B’. A problem to solve The watch is subsequently enhanced to incorporate an alarm and the following interaction sets the time of the alarm: Press A; press A; press B (repeatedly); press A; press B (repeatedly); press A; The intention is that the user presses button A in quick succession, (like a double click with a mouse) to move to the “alarm setting” mode. A problem to solve What does this do? What does this mean? A problem to solve Can you read the above diagram ? A problem to solve .
Load more

Recommended publications
  • Activity Diagram Inheritance1
    Activity Diagram Inheritance1 Arnd Schnieders, Frank Puhlmann Hasso-Plattner-Institute for IT Systems Engineering at the University of Potsdam {schnieders, puhlmann}@hpi.uni-potsdam.de Abstract This paper outlines the ongoing work on the realization of a flexible inheritance mechanism for Activity Diagrams that assures the maintenance of syntactical correctness for the derived Activity Diagrams. The objective is to support the reuse of process models especially by applying Activity Diagram inheritance as a variability mechanism in the context of product line oriented software development. Keywords: Activity Diagrams, domain engineering, process inheritance, variability mechanism 1. Introduction In industry similar products are frequently developed and produced as product lines. One of the main advantages is a gain of efficiency in development and production since parts, which are common for several product line members, can be reused optimally. This approach has been transferred successfully to software development and is also known by the name domain engineering. Variability mechanisms are thereby important for the effectiveness of domain engineering. A great number of variability mechanisms has already been published [5, 9, 11, 13, 18]. Unfortunately, existing variability mechanisms only refer to the static aspects of a software system’s design while the impact of variability mechanisms on the process view on the system has been strongly neglected. Therefore, the first contribution of this paper is to contribute to closing this gap by making the important variability mechanism inheritance available for process design models in order to derive process model variants. The second contribution of this paper is to show how the defined process inheritance mechanism is realized concretely for UML 2.0 Activity Diagrams.
    [Show full text]
  • OMG Systems Modeling Language (OMG Sysml™) Tutorial 25 June 2007
    OMG Systems Modeling Language (OMG SysML™) Tutorial 25 June 2007 Sanford Friedenthal Alan Moore Rick Steiner (emails included in references at end) Copyright © 2006, 2007 by Object Management Group. Published and used by INCOSE and affiliated societies with permission. Status • Specification status – Adopted by OMG in May ’06 – Finalization Task Force Report in March ’07 – Available Specification v1.0 expected June ‘07 – Revision task force chartered for SysML v1.1 in March ‘07 • This tutorial is based on the OMG SysML adopted specification (ad-06-03-01) and changes proposed by the Finalization Task Force (ptc/07-03-03) • This tutorial, the specifications, papers, and vendor info can be found on the OMG SysML Website at http://www.omgsysml.org/ 7/26/2007 Copyright © 2006,2007 by Object Management Group. 2 Objectives & Intended Audience At the end of this tutorial, you should have an awareness of: • Benefits of model driven approaches for systems engineering • SysML diagrams and language concepts • How to apply SysML as part of a model based SE process • Basic considerations for transitioning to SysML This course is not intended to make you a systems modeler! You must use the language. Intended Audience: • Practicing Systems Engineers interested in system modeling • Software Engineers who want to better understand how to integrate software and system models • Familiarity with UML is not required, but it helps 7/26/2007 Copyright © 2006,2007 by Object Management Group. 3 Topics • Motivation & Background • Diagram Overview and Language Concepts • SysML Modeling as Part of SE Process – Structured Analysis – Distiller Example – OOSEM – Enhanced Security System Example • SysML in a Standards Framework • Transitioning to SysML • Summary 7/26/2007 Copyright © 2006,2007 by Object Management Group.
    [Show full text]
  • Sysml, the Language of MBSE Paul White
    Welcome to SysML, the Language of MBSE Paul White October 8, 2019 Brief Introduction About Myself • Work Experience • 2015 – Present: KIHOMAC / BAE – Layton, Utah • 2011 – 2015: Astronautics Corporation of America – Milwaukee, Wisconsin • 2001 – 2011: L-3 Communications – Greenville, Texas • 2000 – 2001: Hynix – Eugene, Oregon • 1999 – 2000: Raytheon – Greenville, Texas • Education • 2019: OMG OCSMP Model Builder—Fundamental Certification • 2011: Graduate Certification in Systems Engineering and Architecting – Stevens Institute of Technology • 1999 – 2004: M.S. Computer Science – Texas A&M University at Commerce • 1993 – 1998: B.S. Computer Science – Texas A&M University • INCOSE • Chapters: Wasatch (2015 – Present), Chicagoland (2011 – 2015), North Texas (2007 – 2011) • Conferences: WSRC (2018), GLRCs (2012-2017) • CSEP: (2017 – Present) • 2019 INCOSE Outstanding Service Award • 2019 INCOSE Wasatch -- Most Improved Chapter Award & Gold Circle Award • Utah Engineers Council (UEC) • 2019 & 2018 Engineer of the Year (INCOSE) for Utah Engineers Council (UEC) • Vice Chair • Family • Married 14 years • Three daughters (1, 12, & 10) 2 Introduction 3 Our Topics • Definitions and Expectations • SysML Overview • Basic Features of SysML • Modeling Tools and Techniques • Next Steps 4 What is Model-based Systems Engineering (MBSE)? Model-based systems engineering (MBSE) is “the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.” -- INCOSE SE Vision 2020 5 What is Model-based Systems Engineering (MBSE)? “Formal systems modeling is standard practice for specifying, analyzing, designing, and verifying systems, and is fully integrated with other engineering models. System models are adapted to the application domain, and include a broad spectrum of models for representing all aspects of systems.
    [Show full text]
  • Plantuml Language Reference Guide (Version 1.2021.2)
    Drawing UML with PlantUML PlantUML Language Reference Guide (Version 1.2021.2) PlantUML is a component that allows to quickly write : • Sequence diagram • Usecase diagram • Class diagram • Object diagram • Activity diagram • Component diagram • Deployment diagram • State diagram • Timing diagram The following non-UML diagrams are also supported: • JSON Data • YAML Data • Network diagram (nwdiag) • Wireframe graphical interface • Archimate diagram • Specification and Description Language (SDL) • Ditaa diagram • Gantt diagram • MindMap diagram • Work Breakdown Structure diagram • Mathematic with AsciiMath or JLaTeXMath notation • Entity Relationship diagram Diagrams are defined using a simple and intuitive language. 1 SEQUENCE DIAGRAM 1 Sequence Diagram 1.1 Basic examples The sequence -> is used to draw a message between two participants. Participants do not have to be explicitly declared. To have a dotted arrow, you use --> It is also possible to use <- and <--. That does not change the drawing, but may improve readability. Note that this is only true for sequence diagrams, rules are different for the other diagrams. @startuml Alice -> Bob: Authentication Request Bob --> Alice: Authentication Response Alice -> Bob: Another authentication Request Alice <-- Bob: Another authentication Response @enduml 1.2 Declaring participant If the keyword participant is used to declare a participant, more control on that participant is possible. The order of declaration will be the (default) order of display. Using these other keywords to declare participants
    [Show full text]
  • Sysml Distilled: a Brief Guide to the Systems Modeling Language
    ptg11539604 Praise for SysML Distilled “In keeping with the outstanding tradition of Addison-Wesley’s techni- cal publications, Lenny Delligatti’s SysML Distilled does not disappoint. Lenny has done a masterful job of capturing the spirit of OMG SysML as a practical, standards-based modeling language to help systems engi- neers address growing system complexity. This book is loaded with matter-of-fact insights, starting with basic MBSE concepts to distin- guishing the subtle differences between use cases and scenarios to illu- mination on namespaces and SysML packages, and even speaks to some of the more esoteric SysML semantics such as token flows.” — Jeff Estefan, Principal Engineer, NASA’s Jet Propulsion Laboratory “The power of a modeling language, such as SysML, is that it facilitates communication not only within systems engineering but across disci- plines and across the development life cycle. Many languages have the ptg11539604 potential to increase communication, but without an effective guide, they can fall short of that objective. In SysML Distilled, Lenny Delligatti combines just the right amount of technology with a common-sense approach to utilizing SysML toward achieving that communication. Having worked in systems and software engineering across many do- mains for the last 30 years, and having taught computer languages, UML, and SysML to many organizations and within the college setting, I find Lenny’s book an invaluable resource. He presents the concepts clearly and provides useful and pragmatic examples to get you off the ground quickly and enables you to be an effective modeler.” — Thomas W. Fargnoli, Lead Member of the Engineering Staff, Lockheed Martin “This book provides an excellent introduction to SysML.
    [Show full text]
  • Sysml Activity Diagram Some Basic Semantics [email protected]
    SysML Activity Diagram Some Basic Semantics [email protected] 1. Does this diagram follow all SysML rules, is it semantically correct? 2. If it is correct, is it good SysML, is the modeler’s intent clear? 3. What is the modeler’s intent? The semantics discussed are not comprehensive; rather, they are meant to cover only some of the most common usages. Readers are encouraged to consult additional documentation to obtain a fuller understanding of the SysML grammar. Activity Edges Control and Object Flows Control Flow Object Flow The most basic function of Activity Diagrams is the Object flow Pin. Control flow activity edge, commutation of information activity edge, solid line. among Actions. This is dashed line. accomplished by using either or both types of activity edges, as required: Best Practices 1. Use Object Flows whenever possible as they explicitly specify what is being communicated between Actions. 2. The two object flow constructs on the right are semantically identical. In general, the use of pins is preferred as it is more concise and allows for typecasting, should that be required. Activity Edge Semantics 1. An Action cannot start until all Control and Object tokens are received at the Action edge. 2. When an Action finishes, it provides all Control and Object tokens to their respective flows. Diagram Flow Discussion 1. When A finishes, it provides The Activity Diagram on the Control tokens to B and C at the left is grammatically correct. same time. However, the Control Flow 2. B then starts. When B finishes, it between A and B is provides a Control token to C.
    [Show full text]
  • The Validation Possibility of Topological Functioning Model Using the Cameo Simulation Toolkit
    The Validation Possibility of Topological Functioning Model using the Cameo Simulation Toolkit Viktoria Ovchinnikova and Erika Nazaruka Department of Applied Computer Science, Riga Technical University, Setas Street 1, Riga, Latvia Keywords: Topological Functioning Model, Execution Model, Foundational UML, UML Activity Diagram. Abstract: According to requirements provided by customers, the description of to-be functionality of software systems needs to be provided at the beginning of the software development process. Documentation and functionality of this system can be displayed as the Topological Functioning Model (TFM) in the form of a graph. The TFM must be correctly and traceably validated, according to customer’s requirements and verified, according to TFM construction rules. It is necessary for avoidance of mistakes in the early stage of development. Mistakes are a risk that can bring losses of resources or financial problems. The hypothesis of this research is that the TFM can be validated during this simulation of execution of the UML activity diagram. Cameo Simulation Toolkit from NoMagic is used to supplement UML activity diagram with execution and allows to simulate this execution, providing validation and verification of the diagram. In this research an example of TFM is created from the software system description. The obtained TFM is manually transformed to the UML activity diagram. The execution of actions of UML activity diagrams was manually implemented which allows the automatic simulation of the model. It helps to follow the traceability of objects and check the correctness of relationships between actions. 1 INTRODUCTION It represents the full scenario of system functionality and its relationships. Development of the software system is a complex The simulation of models can help to see some and stepwise process.
    [Show full text]
  • UML Notation Guide
    UML Notation Guide version 1.1 1 September 1997 Rational Software ■ Microsoft ■ Hewlett-Packard ■ Oracle Sterling Software ■ MCI Systemhouse ■ Unisys ■ ICON Computing IntelliCorp ■ i-Logix ■ IBM ■ ObjecTime ■ Platinum Technology ■ Ptech Taskon ■ Reich Technologies ■ Softeam ad/97-08-05 Copyright © 1997 Rational Software Corporation Copyright © 1997 Microsoft Corporation Copyright © 1997 Hewlett-Packard Company. Copyright © 1997 Oracle Corporation. Copyright © 1997 Sterling Software. Copyright © 1997 MCI Systemhouse Corporation. Copyright © 1997 Unisys Corporation. Copyright © 1997 ICON Computing. Copyright © 1997 IntelliCorp. Copyright © 1997 i-Logix. Copyright © 1997 IBM Corporation. Copyright © 1997 ObjecTime Limited. Copyright © 1997 Platinum Technology Inc. Copyright © 1997 Ptech Inc. Copyright © 1997 Taskon A/S. Copyright © 1997 Reich Technologies Copyright © 1997 Softeam Photocopying, electronic distribution, or foreign-language translation of this document is permitted, provided this document is reproduced in its entirety and accompanied with this entire notice, including the following statement: The most recent updates on the Unified Modeling Language are available via the worldwide web: http://www.rational.com/uml The UML logo is a trademark of Rational Software Corporation. Contents 1. DOCUMENT OVERVIEW 1 2. DIAGRAM ELEMENTS 3 2.1 Graphs and their Contents . 3 2.2 Drawing paths . 4 2.3 Invisible Hyperlinks And The Role Of Tools . 4 2.4 Background information . 4 2.5 String . 5 2.6 Name . 6 2.7 Label . 7 2.8 Keywords. 8 2.9 Expression . 8 2.10 Note . 10 2.11 Type-Instance Correspondence . 11 3. MODEL MANAGEMENT 13 3.1 Packages and Model Organization . 13 4. GENERAL EXTENSION MECHANISMS 16 4.1 Constraint and Comment . 16 4.2 Element Properties.
    [Show full text]
  • State and Activity Diagrams in UML Last Revised December 4, 2018 Objectives: 1
    CPS122 Lecture: State and Activity Diagrams in UML last revised December 4, 2018 Objectives: 1. To show how to create and read State Diagrams 2. To introduce UML Activity Diagrams Materials: 1. Answers to quick check questions from chapter 7 plus chapter 8 a, b, g 2. Demonstration of “Racers” program 3. Handout and Projectable on Web: State diagram for Session 4. Handout: Code for Session class performSession() method 5. Projectable of text figures 7.12, 7.13 6. Handout of Activity diagram for Racers 7. Projectable of text figure 8.10 I. Introduction A.Go over quick check questions chapter 7 + chapter 8 a, b, g only B. We have drawn a distinction between the static aspects of a system and its dynamic aspects. The static aspects of a system have to do with its component parts and how they are related to one another; the dynamic aspects of a system have to do with how the components interact with one another and/or change state internally over time. C. We have been looking at one aspect of the dynamic behavior of a system - the way various objects interact to carry out the various use cases. We have looked at two ways of describing this: 1. Sequence diagrams 2. Communication diagrams D.We now want to look two additional aspects of dynamic behavior !1 1. How an individual object changes state internally over time. a) Example: As part of doing the domain analysis of a traffic light system, it is important to note that individual signals go through a series of states in a prescribed order - modeled by the following state diagram: ! (Note: this is correct for the US but not for all countries in the world!) An important “business rule” that any traffic light system must obey is that the light must be yellow for a certain minimum period of time (related to vehicle speed in the intersection) between displaying green and displaying red.
    [Show full text]
  • During the Early Days of Computing, Computer Systems Were Designed to Fit a Particular Platform and Were Designed to Address T
    TAGDUR: A Tool for Producing UML Diagrams Through Reengineering of Legacy Systems Richard Millham, Hongji Yang De Montfort University, England [email protected] & [email protected] Abstract: Introducing TAGDUR, a reengineering tool that first transforms a procedural legacy system into an object-oriented, event-driven system and then models and documents this transformed system through a series of UML diagrams. Keywords: TAGDUR, Reengineering, Program Transformation, UML In this paper, we introduce TAGDUR (Transformation from a sequential-driven, procedural structured to an and Automatic Generation of Documentation in UML event-driven, component-based architecture requires a through Reengineering). TAGDUR is a reengineering tool transformation of the original system to an object-oriented, designed to address the problems frequently found in event-driven system. Object orientation, because it many legacy systems such as lack of documentation and encapsulates methods and their variables into modules, is the need to transform the present structure to a more well-suited to a multi-tiered Web-based architecture modern architecture. TAGDUR first transforms a where pieces of software must be defined in encapsulated procedurally-structured system to an object-oriented, modules with cleanly-defined interfaces. This particular event-driven architecture. Then TAGDUR generates legacy system is procedural-driven and is batch-oriented; documentation of the structure and behavior of this a move to a Web-based architecture requires a real-time, transformed system through a series of UML (Unified event-driven response rather than a procedural invocation. Modeling Language) diagrams. These diagrams include class, deployment, sequence, and activity diagrams. Object orientation promises other advantages as well.
    [Show full text]
  • Activity Diagrams Analytical Tools
    A/L ICT Activity Diagrams Analytical Tools Lecturer - Teran Subasinghe AURORA COMPUTER STUDIES 1 ACTIVITY DIAGRAMS Activity diagrams, which are related to program flow plans (flowcharts), are used to illustrate activities. In the external view, we use activity diagrams for the description of those business processes that describe the functionality of the business system. Contrary to use case diagrams, in activity diagrams it is obvious whether actors can perform business use cases together or independently from one another. The following illustrates a basic activity diagram: Activity diagram “Passenger Services” with a low level of detail (“High Level”) LECTURER - TERAN SUBASINGHE 1 2 Activity diagram of the activity “Passenger checks in” ACTIVITY An activity diagram illustrates one individual activity. In our context, an activity represents a business process. Fundamental elements of the activity are actions and control elements (decision, division, merge, initiation, end, etc.): Lecturer - Teran Subasinghe | AURORA COMPUTER STUDIES 3 ACTION An action is an individual step within an activity, for example, a calculation step that is not deconstructed any further. That does not necessarily mean that the action cannot be subdivided in the real world, but in this diagram will not be refined any further: The action can possess input and output information. The output of one action can be the input of a subsequent action within an activity. Specific actions are calling other actions, receiving an event, and sending signals. CALLING AN ACTIVITY (ACTION) With this symbol an activity can be called from within another activity. Calling, in itself, is an action; the outcome of the call is another activity: In this way, activities can be nested within each other and can be represented with different levels of detail.
    [Show full text]
  • Case No COMP/M.4747 Œ IBM / TELELOGIC REGULATION (EC)
    EN This text is made available for information purposes only. A summary of this decision is published in all Community languages in the Official Journal of the European Union. Case No COMP/M.4747 – IBM / TELELOGIC Only the English text is authentic. REGULATION (EC) No 139/2004 MERGER PROCEDURE Article 8(1) Date: 05/03/2008 Brussels, 05/03/2008 C(2008) 823 final PUBLIC VERSION COMMISSION DECISION of 05/03/2008 declaring a concentration to be compatible with the common market and the EEA Agreement (Case No COMP/M.4747 - IBM/ TELELOGIC) COMMISSION DECISION of 05/03/2008 declaring a concentration to be compatible with the common market and the EEA Agreement (Case No COMP/M.4747 - IBM/ TELELOGIC) (Only the English text is authentic) (Text with EEA relevance) THE COMMISSION OF THE EUROPEAN COMMUNITIES, Having regard to the Treaty establishing the European Community, Having regard to the Agreement on the European Economic Area, and in particular Article 57 thereof, Having regard to Council Regulation (EC) No 139/2004 of 20 January 2004 on the control of concentrations between undertakings1, and in particular Article 8(1) thereof, Having regard to the Commission's decision of 3 October 2007 to initiate proceedings in this case, After consulting the Advisory Committee on Concentrations2, Having regard to the final report of the Hearing Officer in this case3, Whereas: 1 OJ L 24, 29.1.2004, p. 1 2 OJ C ...,...200. , p.... 3 OJ C ...,...200. , p.... 2 I. INTRODUCTION 1. On 29 August 2007, the Commission received a notification of a proposed concentration pursuant to Article 4 and following a referral pursuant to Article 4(5) of Council Regulation (EC) No 139/2004 ("the Merger Regulation") by which the undertaking International Business Machines Corporation ("IBM", USA) acquires within the meaning of Article 3(1)(b) of the Council Regulation control of the whole of the undertaking Telelogic AB ("Telelogic", Sweden) by way of a public bid which was announced on 11 June 2007.
    [Show full text]