Architecture-Centric Evolution in
Software Product Lines:
Position Paper
Hassan Gomaa
Department of Information and Software Engineering
George Mason University
Fairfax, Virginia 22030,
USA
hgomaa@https://www.doczj.com/doc/4b14116342.html,
Abstract:This paper describes how an architecture-centric evolution approach can be used to develop and evolve software product line architectures. The architecture-centric evolution approach described in this paper uses a model driven architecture concept in which UML models of the software architecture are developed prior to implementation and later evolved after original deployment.
1. Introduction
A software product line consists of a family of software systems that have some common functionality and some variable functionality [Parnas79, Clements02, Weiss99]. This paper describes an architecture-centric evolutionary development approach for software product lines. This paper advocates that a much clearer idea about how to develop and evolve the software product line is obtained by considering the software architecture rather than by starting directly from the code.
The architecture-centric evolution approach described in this paper follows the model driven architecture concept in which UML models of the software architecture are developed prior to implementation. With this approach, the models can later evolve after original deployment. The kernel software architecture represents the commonality of the product line. Evolution is built into the software development approach because the variability in the software architecture is developed by considering the impact of each variable feature on the software architecture and evolving the architecture to address the feature. The development approach is a feature-driven evolutionary approach, meaning that it addresses both the original development and subsequent post-deployment evolution. Being feature based, the approach closely relates the software architecture evolution to the evolution of software requirements.
2 Hassan Gomaa
This paper addresses the key factors needed for architecture centered evolution of software product lines, which include:
-Evolutionary software process model. It is necessary to have a development approach that promotes software evolution, such that original development
and subsequent maintenance are both treated using feature-driven evolution.
-Model-driven software architecture, in which the architecture is developed before the code.
-Evolutionary dynamic analysis. Consider the dynamic impact of each feature on the architecture. The results in new components being added or existing
components having to be adapted.
-Specialization vs. parameterization. When components are adapted for evolution, there are two main approaches to consider, specialization or
parameterization.
-Component based design. Software components, in which the interface is separate from the implementation. Components differ from objects in that
the required interface is designed explicitly in addition to the provided
interface.
-Software architectural patterns. Architectural structure and communication patterns help in developing and evolving the software architecture.
2. Evolutionary Software Product Line Engineering
The Evolutionary Software Product Line Engineering Process [Gomaa99, Gomaa04] is a highly iterative software process that eliminates the traditional distinction between software development and maintenance. Furthermore, because new software systems are outgrowths of existing ones, the process takes a software product line perspective; it consists of two main processes:
a) Product line Engineering. A product line multiple-view model, which addresses the multiple views of a software product line, is developed. The product line multiple-view model, product line architecture, and reusable components are developed and stored in the product line reuse library.
b) Software Application Engineering. A software application multiple-view model is an individual product line member derived from the software product line multiple-view model. The user selects the required features for the individual product line member. Given the features, the product line model and architecture are adapted and tailored to derive the application architecture. The architecture determines which of the reusable components are needed for configuring the executable application.
3. Model-driven Architecture
The Object Management Group (OMG) promotes model-driven architecture whereby “modeling is designing of software applications before coding”. Software
Architecture-Centric Evolution in
Software Product Lines: 3 modeling approaches are now widely used in software development and have an important role to play in software product lines [Gomaa04]. Modern software modeling approaches, such as the Unified Modeling Language (UML) [Rumbaugh04], provide greater insights into understanding and managing commonality and variability by modeling product lines from different perspectives. A better understanding of the software product line architecture can be obtained by considering the different perspectives, such as requirements modeling, static modeling, and dynamic modeling, of the product line.
4. Evolutionary Dynamic Analysis.
Evolutionary dynamic analysis is an iterative strategy to help determine the dynamic impact of each feature on the software architecture. This results in new components being added or existing components having to be adapted. The kernel system is a minimal member of the product line. In some product lines the kernel system consists of only the kernel objects. For other product lines, some default objects may be needed in addition to the kernel objects. The kernel system is developed by considering the kernel use cases, which are required by every member
for the product line. For each kernel use case, an interaction diagram is developed depicting the objects needed to realize the use case. The kernel system consists of the integration of all these objects and the classes from which they are instantiated, as described in [Gomaa00, Gomaa04].
The software product line evolution approach starts with the kernel system and considers the impact of optional and/or alternative features. This results in the addition of optional or variant components to the product line architecture. This analysis is done by considering the variable (optional and alternative) use cases, as well as any variation points in the kernel or variable use cases. For each optional or alternative use case, an interaction diagram is developed consisting of new optional or variant objects – the variant objects are kernel objects that are impacted by the variable scenarios, and therefore need to be adapted.
5. Managing Variability through Specialization and Parameterization
When components are adapted for evolution, there are two main approaches to consider, specialization or parameterization. Specialization is effective when there are
a relatively small number of changes to be made, so that the number of specialized classes is manageable. However, in product line evolution, there can be a large degree
of variability. Consider the issue of variability in control classes, which are modeling using statecharts [Harel96], which can be handled either by using parameterized statecharts or specialized statecharts. Depending on whether the product line uses a centralized or decentralized approach, it is likely that there will be several different
4 Hassan Gomaa
state dependent control components, each modeled by its own statechart. The following discussion relates to the evolution within a given state dependent component.
To capture product line variability and evolution, it is necessary to specify optional states, events and transitions, and actions. A further decision that needs to be made when using state machines to model variability is whether to use state machine inheritance or parameterization. The problem with using inheritance is that a different state machine is needed to model each alternative or optional feature or feature combination, which rapidly leads to a combinatorial explosion of inherited state machines.
For example, with only three features that could impact the statechart, there would be eight possible feature and feature combinations, resulting in eight variant statecharts. With 10 features, there would be over 1000 variant statecharts. However, 10 features can be easily modeled on a parameterized statechart as 10 feature dependent transitions, states, or transitions.
It is often more effective to design a parameterized state machine, which consists of all states, events, and transitions, corresponding to all features Optional transitions can be specified by having an event qualified by a feature condition, which guards entry into the state. Thus the feature condition is True if the optional feature is selected for a given product line member, and false if the feature is not selected. The impact of feature interactions can be modeled very precisely using state machines through the introduction of alternative states or transitions. Designing parameterized statecharts is often less complex than designing specialized statecharts.
6. Modeling Component-based Software Architectures
Software components are similar to classes in that the component interface is specified separately from the implementation. However, components differ from classes in that the required interface is designed explicitly in addition to the provided interface. This is particularly important for architecture-centric evolution, since it is necessary to know the impact of the change to a component on all components that interface to it.
UML 2.0 has added new concepts for depicting software architectures and components. Components can be effectively modeled with structured classes and depicted on composite structure diagrams [Rumbaugh04]. Structured classes have ports with provided and required interfaces. Structured classes can be interconnected through their ports via connectors that join the ports of communicating classes.
To provide a complete definition of the component-based software architecture for a software product line, it is necessary to specify the interface(s) provided by each component and the interface(s) required by each component. A provided interface is
Architecture-Centric Evolution in
Software Product Lines: 5
a collection of operations that specify the services that a component must fulfill. A required interface describes the services that other components provide for this component to operate properly in a particular environment.
This capability for modeling component-based software architectures is particularly valuable in product line engineering, to allow the development of kernel, optional and variant components, “plug-compatible” components, and component interface inheritance.
There are various ways to design components. It is highly desirable, where possible, to design components that are plug-compatible, so that the required port of one component is compatible with the provided ports of other components to which it needs to connect. Consider the case in which a producer component needs to be able to connect to different alternative consumer components in different product line members. The most desirable approach, if possible, is to design all the consumer components with the same provided interface, so that the producer can be connected to any consumer without changing its required interface. As the product line evolves new producers can communicate with the consumer.
It is possible for a component to connect to different components and have different interconnections such that in one case it communicates with one component and in a different case it communicates with two different components. This flexibility helps in evolving the software architecture.
When plug-compatible components are not practical, an alternative component design approach is component interface inheritance. Consider a component architecture that evolves in such a way that the interface through which the two components communicate needs to be specialized to allow for additional functionality. In this case, both the component that provides the interface and the component that requires the interface have to be modified—the former to realize the new functionality, and the latter to request it.
The above approaches can be used to complement compositional approaches for developing component-based software architectures.
7. Software Architectural Patterns
Basing the software architecture on one or more software architectural patterns, both architectural structure patterns and architectural communication patterns, helps in designing the original architecture as well as evolving the architecture [Gomaa98, Gomaa04]. This is because the evolutionary properties of architectural patterns can also be studied. For example, a layered architectural pattern allows for ease of extension and contraction [Parnas79] because components can be added to or removed from higher layers that use the services provided by components at lower layers of the architecture. In a centralized control pattern, evolution takes the form of
6 Hassan Gomaa
added input and output components that interact with a controlling control object, which executes a statechart that can evolve as described in Section 5. In a client/server pattern, the server can evolve by adding new services, which are discovered and invoked by clients.
In addition to the above architectural structure patterns, certain architectural communication patterns also encourage evolution. In software product lines, it is often desirable to decouple components. The Broker, Discovery, and Subscription/Notification patterns encourage such decoupling. With the broker patterns, servers register with brokers, and clients can then discover new servers. Thus a product line can evolve with the addition of new clients and servers. A new version of a server can replace an older version and register itself with the broker. Clients communicating via the broker would automatically be connected to the new version of the server. The Subscription/Notification pattern also decouples the original sender of the message from the recipients of the message.
8. Conclusions
This paper has described an architecture-centric evolutionary development approach for software product lines. This paper has discussed several key factors to consider for architecture centered evolution of software product lines, which assist in developing the software architecture before implementation and later evolving the software product line architecture after original deployment.
9. References
[Clements02] P. Clements and L. Northrop, Software Product Lines: Practices and Patterns, Addison Wesley, 2002.
[Gomaa98]H. Gomaa and G. Farrukh, Composition of Software Architectures from Reusable Architecture Patterns, Proc. IEEE Intl Wkshp on Soft Arch, Orlando, FL, Nov 1998. [Gomaa99] H. Gomaa and G.A. Farrukh, Methods and Tools for the Automated Configuration of Distributed Applications from Reusable Software Architectures and Components, IEE Proc - Software, Vol. 146, No. 6, December 1999.
[Gomaa00] H. Gomaa, "Designing Concurrent, Distributed, and Real-Time Applications with UML", Addison Wesley, Reading MA, 2000.
[Gomaa04] Gomaa, H. Designing Software Product Lines with UML: From Use Cases to Pattern-based Software Architectures, Addison-Wesley, July 2004.
[Harel96] Harel, D. and E. Gary, “Executable Object Modeling with Statecharts”, Proc. 18th International Conference on Software Engineering, Berlin, March 1996.
[Parnas79] Parnas D., "Designing Software for Ease of Extension and Contraction", IEEE Transactions on Software Engineering, March 1979.
[Rumbaugh04] J. Rumbaugh, G. Booch, I. Jacobson, “The Unified Modeling Language Reference Manual,” Second Edition, Addison Wesley, Reading MA, 2004.
[Weiss99] D M Weiss and C T R Lai, “Software Product-Line Engineering: A Family-Based Software Development Process,” Addison Wesley, 1999.
南车四方机车车辆股份有限公司 青岛喜盈门集团公司 青岛广源发集团有限公司 青岛美高集团有限公司 济南山水集团有限公司青岛水泥分公司青岛正进集团有限公司 青岛大农服装有限公司 山东黄岛发电厂 青岛金晶股份有限公司 青岛恒源热电有限公司 青岛浮法玻璃有限公司 青岛压花玻璃有限公司 青岛市圣戈班韩洛玻玻璃有限公司 青岛高合有限公司 青岛浦项不锈钢有限公司 青岛北海船舶重工有限责任公司 青岛经济技术开发区热电燃气总公司 青岛赛轮子午线轮胎信息化生产示范基地 1 即墨市热电厂 青岛即发集团控股有限公司 青岛新源热电有限公司 青岛三湖制鞋有限公司 青岛正大有限公司 青岛高丽钢线有限公司 青岛北汇玻璃有限公司 即墨市双春水泥有限公司 青岛红领服饰股份有限公司 青岛恒光热电有限公司 青岛恒源化工有限公司 青岛天元化工股份有限公司 青岛海王纸业股份有限公司 青岛琅琊台酒业（集团）股份有限公司青岛胶南明月海藻工业有限责任公司 胶南易通热电有限责任公司 青岛泰发集团股份有限公司 青岛东亚轮胎有限公司
青岛康大外贸集团有限公司 胶南供电公司 胶南市水泥厂 2 胶南市海龙福利板纸有限公司 青岛振华工业集团有限公司 青岛德固萨化学有限公司 青岛龙发热电有限公司 青岛恒祥化肥有限公司 青岛世原鞋业有限公司 青岛华威建材有限公司 青岛广源发玻璃有限公司 青岛大明皮革有限公司 青岛昌新鞋业有限公司 青岛衣东纺织有限公司 青岛海尔金塑制品有限公司 山东金湖水泥有限公司青岛分公司 青岛福生食品有限公司 青岛信五皮革有限公司 青岛多福康食品有限公司 胶州天成玻璃工艺品厂 胶州市新纪元帘子布有限公司 青岛昌华集团股份有限公司 青岛热电集团金莱热电有限公司 青岛金浪热电有限公司 3 青岛泰光制鞋有限公司 青岛现代人热力发展有限公司 青岛金浪化工集团有限公司 青岛凤凰东翔印染有限公司 青岛九联集团股份有限公司 青岛海升果业有限责任公司 青岛交河技工塑料有限公司 青岛东方化工股份有限公司 海尔集团公司 青岛崂山玻璃有限公司 青岛啤酒第五有限公司
注意：以下内容请进一步总结！ 青岛恒源热电有限公司 目标公司主要从事蒸汽、热水的生产及供应、蒸汽余热发电业务，同时提供供热管道及设施维修、安装业务。据介绍，目标公司开发了循环水供热工程项目，该项目是青岛市获批的第一个清洁发展机制(CDM)项目；前处该项目处于施工建设阶段，预计将于2009年上半年内正式投产。据介绍，目标公司主要负责临港工业区辖区内的蒸汽供应及热网管理，发电业务，对居民的用热服务。 公司成立于2001年，主要从事蒸汽、热水的生产及供应、蒸汽余热发电业务。 青岛恒源热电有限公司位于开发区B区供热范围，拥有12MW的抽凝式汽轮发电机组1台及12MW的背压机组1台，75t/h循环流化床锅炉3台和150t/h锅炉1台，最大供热能力是355t/h，担负着B区的生产、民用供热负荷，主要满足热电厂东部居民小区供热和山东科技大学供热。 青岛恒源热电有限公司位于青岛经济技术开发区临港工业区的中北部，海尔大道与渭河路交界处东北角，渭河路777号。厂区所在地东侧隔宽约100m绿化地为鑫龙物流公司，该公司东侧、距离本项目最近300m处为澳柯玛人才公寓；厂区南侧隔渭河路、绿化带100m处为东小庄村（原村庄平房已搬迁，现建有多座两层复式楼房），该村庄南侧、距离本项目约420m处为山孚日水食品有限公司；项目隔渭河路东南方向约200m处为澳柯玛工业园；西及西南方向隔海尔大道、渭河路均为浦项制铁有限公司；北侧与开发区消防大队以及正友砼业相邻。 企业所在地厂址东南距市中心约8km，东面距前湾港区约4.5km。 现有工程内容：青岛恒源热电有限公司主要服务于黄岛供热分区B 区（齐长城路以北、疏港高速以南、镰湾河以西、柳花泊和珠山以东片区（包括柳花泊），总占地面积约60平方公里）。企业现有锅炉规模为3×75t/h+1×130t/h 循环流化床蒸汽锅炉，总计约355t/h锅炉容量；发电机组规模为1×12MW C12-34.9/0.98（抽凝）+1×12MW B12-4.9/0.98（背压），总计发电装机容量24 MW。 近几年，恒源热电强化能源管理，合理调整运行方式，加强节能技术改造，企业能源管理工作上了一个新台阶，先后通过了“企业能源审计”、“热电联产机组认定”等审核认证工作，被评为“青岛市清洁生产企业”，2007年度“山东省节能先进企业”。 为进一步加强企业能源管理，完善优化企业节能减排工作，公司在本年度开始推行循环经济试点工作。目前，作为试点工作重点项目之一的企业冷渣机改造项目已基本完成，初步具备投运条件，预计本年度六月份正式投入运行。该项目是将循环流化床锅炉的人工排渣（温度一般在900℃），通过加装冷渣机把炉渣余热加热除盐水，将锅炉效率提高1-3%，同时解决人工放渣存在安全隐患、能源浪费以及不环保等问题，项目投资为85万元，年可节标煤700吨。
热能与动力工程专业制热方向认识 实习报告 学院：机电工程学院 班级：热能一班 姓名：徐国庆 学号：201240502013
一．认识实习的目的和任务 1.认识实习的目的： （1）认识实习是四年制高等学校教学活动的实践环节之一； （2）认识实习是对学生进行火力发电厂主机（锅炉、汽轮机）、辅机（换热器、风机、水泵）及其制造厂的设备系统、生产工艺进行认识性训 练，对发电厂热力系统进行整体初步了解。 2.认识实习的任务： （1）对火力发电厂主机的认识实习 实习对象：锅炉本体、汽轮发电机本体。锅炉形式包括煤粉锅炉、循 环流化床锅炉、链条炉、余热锅炉等。汽轮机形式包括凝气式汽轮机、 背压式汽轮机、调节抽汽式汽轮机。 认识内容：设备外形特点、摆放位置、主要性能参数、安全生产常识。 （2）对火力发电厂辅助机械设备的认识实习 实习对象：制粉系统、除尘除灰系统、烟风系统、回热系统、润滑冷 却系统、水油净化系统等。 认识内容：设备外形特点、摆放位置、主要性能参数、安全生产常识。 （3）对火力发电厂设备系统的认识实习 实习对象：火力发电厂主机和辅机工程的系统。 认识内容：设备之间的空间关系、安全生产常识。 3.认识实习的意义 （1）强化学生对专业基础课程的理解 （2）国内火力发电厂的技术发展出现了新进展 CFB锅炉、燃气轮机、余热锅炉、超临界机组、烟气脱硫、布袋除尘、集中控制运行等新技术。 （3）认识实习有利于培养学生的职业精神 （4）认识实习有利于了解机组 （5）认识实习有利于了解机组建设过程 二．捷能汽轮机厂 （1）简介：汽轮机是火力发电厂三大主要设备之一。它是以蒸汽为工质，将热能转变为机械能的高速旋转式原动机。它为发电机的能量转换提供机 械能。 青岛捷能汽轮机集团股份有限公司始建于1950年，是我国汽轮机行业重 点骨干企业。拥有各种数控、数显等机械加工设备2200余台，以200MW 及以下“捷能牌”汽轮机为主导产品，拥有电站汽轮机和工业拖动汽轮 机两大系列产品，能够满足发电、石化、水泥、冶金、造纸、垃圾处理、燃气-蒸汽联合循环、城市集中供热等领域需求，年产能达500台/600万 千瓦以上。中小型汽轮机市场占有率居国内同行业首位，是目前国内中 小型汽轮机最大最强的设计制造供应商和电站成套工程总包商。 公司积极推进品牌战略，率先在汽轮机行业内取得了美国FMRC公司双重 ISO9001国际质量体系认证和ISO1400环境管理体系认证，率先在汽轮机 行业内第一个获得了“中国名牌产品”称号，先后获得了“全国AAA级 信用企业”、“中国优秀诚信企业”、“全国用户满意产品”、“山东
供热管网检修作业指导手册[青岛热电集团] 供热管网检修作业指导手册[青岛热电集团] 供热管网检修作业指导手册[青岛热电集团] 作者:佚名更新时间:2008-12-5 15:55:38 字体: 供热管网检修作业指导手册 1 总则 1.1 为使公司供热管网的维护、检修工作更为规范和科学合理，确保安全运行，制定作业指导手册。 1.2 本作业指导手册适用于公司供热管网的维护、检修及事故抢修。 本作业指导手册供热管网的工作压力限定为: 工作压力不大于1.6MPa(表压)，介质温度不大于300?的蒸汽供热管网。 1.3 管网的检修工作应符合原设计要求。 1.4 执行本作业指导手册时，尚应符合国家现行有关标准的规定。 2 术语 2.1 热网维修 热网的维护和检修。本作业指导手册中简称维修。 2.2 热网维护 供热运行期间，在不停热条件下对热网进行的维护工作。本作业指导手册中简称维护。 2.3 热网检修 在停热条件下对热网进行的检修工作。本作业指导手册中简称检修。 2.4 热网抢修
供热管道设备突发故障引起蒸汽大量泄漏，危及管网安全运行或对周边环境、人身安全造成威胁时进行的紧急检修工作。本作业指导手册中简称抢修。 2.5 供热管网 由热源向热用户输送和分配供热介质的管线系统。本作业指导手册中简称热网。 3 维护、检修机构设置、检修人员及设备 3.1 维护、检修机构设置及人员要求 3.1.1客户服务中心是公司高新区内供热管网运行、调度、维护、检修的责任机构，负责高新区内供热管网的维护、检修工作。 3.1.2 供热管冈的维护、检修人员必须经过培训和专业资格考 试合格后，方可独立进行维护、检修工作。供热管网维护、检修人员必须熟悉管辖范围内的管道分布情况、设备及附件位置。维护、检修人员必须掌握管辖范国内供热管线各种附件的作用、性能、构造以及安装操作和维护、检修方法。 3.1.3检修人员出门检修时应穿公司工作服，配戴上岗证，注意礼貌用语，维护公司形象。 3.2 维护、检修用主要设备与器材 3.2.1 供热管网的维护检修部门，应备有维护、检修及故障抢修时常用的设备与器材。 3.2.2检修设备、工具平时摆放在规定位置，检修设备和专用工具要有专人保管，所有设备、工具应保证完好，须保证检修时能够立即投入使用。检修物资也应分门别类码放整齐，方便查找，以保证检修、抢修时不会因为寻找物资配件而耽误时间。每次检修完后都应检查备品备件数量，发现不够时要及时与物质采购部联系进行必要地补充，确保检修时不会因无备品备件而影响检修时间与质量。
招标投标企业报告 青岛西海岸公用事业集团易通热电有限公司新 能源分公司
本报告于 2019年9月22日 生成 您所看到的报告内容为截至该时间点该公司的数据快照 目录 1. 基本信息：工商信息 2. 招投标情况：中标/投标数量、中标/投标情况、中标/投标行业分布、参与投标 的甲方排名、合作甲方排名 3. 股东及出资信息 4. 风险信息：经营异常、股权出资、动产抵押、税务信息、行政处罚 5. 企业信息：工程人员、企业资质 * 敬启者：本报告内容是中国比地招标网接收您的委托，查询公开信息所得结果。中国比地招标网不对该查询结果的全面、准确、真实性负责。本报告应仅为您的决策提供参考。
一、基本信息 1. 工商信息 企业名称：青岛西海岸公用事业集团易通热电有限公司新能 源分公司 统一社会信用代码：91370211334195493K 工商注册号：370211120004502组织机构代码：334195493法定代表人：赵军田成立日期：2015-04-23 企业类型：有限责任公司分公司(非自然人投资或控股的法人 独资) 经营状态：注销 注册资本：/ 注册地址：山东省青岛市黄岛区相公山路723号 营业期限：2015-04-23 至 / 营业范围：为上级公司联系业务。（依法须经批准的项目，经相关部门批准后方可开展经营活动）联系电话：*********** 二、招投标分析 2.1 中标/投标数量 企业中标/投标数： 个 （数据统计时间：2017年至报告生成时间）
2.2 中标/投标情况（近一年） 截止2019年9月22日，根据国内相关网站检索以及中国比地招标网数据库分析，未查询到相关信息。不排除因信息公开来源尚未公开、公开形式存在差异等情况导致的信息与客观事实不完全一致的情形。仅供客户参考。 2.3 中标/投标行业分布（近一年） 截止2019年9月22日，根据国内相关网站检索以及中国比地招标网数据库分析，未查询到相关信息。不排除因信息公开来源尚未公开、公开形式存在差异等情况导致的信息与客观事实不完全一致的情形。仅供客户参考。 2.4 参与投标的甲方前五名（近一年） 截止2019年9月22日，根据国内相关网站检索以及中国比地招标网数据库分析，未查询到相关信息。不排除因信息公开来源尚未公开、公开形式存在差异等情况导致的信息与客观事实不完全一致的情形。仅供客户参考。 2.5 合作甲方前五名（近一年） 截止2019年9月22日，根据国内相关网站检索以及中国比地招标网数据库分析，未查询到相关信息。不排除因信息公开来源尚未公开、公开形式存在差异等情况导致的信息与客观事实不完全一致的情形。仅供客户参考。 三、股东及出资信息 截止2019年9月22日，根据国内相关网站检索以及中国比地招标网数据库分析，未查询到相关信息。不排除因信息公开来源尚未公开、公开形式存在差异等情况导致的信息与客观事实不完全一致的情形。仅供客户参考。 四、风险信息 4.1 经营异常() 截止2019年9月22日，根据国内相关网站检索以及中国比地招标网数据库分析，未查询到相关信息。不排除因信息公开来源尚未公开、公开形式存在差异等情况导致的信息与客观事实不完全一致的情形。仅供客户参考。 4.2 股权出资() 截止2019年9月22日，根据国内相关网站检索以及中国比地招标网数据库分析，未查询到相关信息。不排除因信息公开来源尚未公开、公开形式存在差异等情况导致的信息与客观事实不完全一致的情形。仅供客户参考。 4.3 动产抵押() 截止2019年9月22日，根据国内相关网站检索以及中国比地招标网数据库分析，未查询到相关信息。不排除因信息公开来源尚未公开、公开形式存在差异等情况导致的信息与客观事实不完全一致的情形。仅供客户参考。 4.4 税务信息() 截止2019年9月22日，根据国内相关网站检索以及中国比地招标网数据库分析，未查询到相关信息。不排除因信息公开来源尚未公开、公开形式存在差异等情况导致的信息与客观事实不完全一致的情形。仅供客户参考。
青岛热电集团有限公司成立于1993年，属于国有独资大型热电联产企业，主要担负着青岛市企、事业单位和居民供热及部分发电任务，同时，供热市场辐射黄岛、平度、莱西、即墨、城阳等县市区域。集团公司先后成立了工程公司和具有甲级设计资质的设计院，逐步形成了热电联产、区域锅炉、热网输配等多种供热形式并存，集供热、发电、热力设计、工程施工、热力产品制造经营为一体的完整产业链。 目前，热电集团为全省地方最大供热企业。企业资产总额48亿元，年销售收入16.2亿元，所属企业16个，职工2200余人，年供蒸汽312万吨，年发电能力9.3万千瓦，已建成蒸汽管网145.43公里，热水管网1552.93公里，供（换）热站294座，供热面积3561万平方米，拥有单位用户292家，居民用户28.8万余户。 集团公司先后被评为全国AAA级信用企业、全国建设系统文明服务示范窗口单位、思想政治工作先进单位、企业文化建设先进单位、精神文明建设先进单位；山东省文明单位、节能先进企业、思想政治工作优秀企业；青岛市和工商年度免检企业、安全生产先进单位、廉洁勤政先进单位；山东省供热协会副理事长单位。 自成立以来，公司始终秉承“关爱社会、服务民生”的企业宗旨和“励精图治、锲而不舍”的企业精神，贯彻科学发展，创新经营管理，实现了企业快速发展。1996年在全国供热行业首家推出社会服务责任赔偿制度，1997年在山东省供热行业首家进行了股份制改造，1998年在山东省供热行业首家成功地进行了集团产权制度改革，1999年在全国同行业中首家通过了ISO9001国际质量认证，并先后通过了ISO14001环境管理体系和GB/T28001-2001职业健康安全管理体系认证，2001年公司成为全国供热行业中首家申请注册服务商标的企业，推出“暖到家”服务品牌，并被评为山东省著名商标和服务名牌。“青岛热电”正在逐步步入标准化、规范化、品牌化的发展轨道。 招聘专业及人数: 1、结构专业1人(研究生)； 2、建筑专业1人(研究生)； 3、技经专业1人(研究生)； 4、焊接技术与工程1人； 5、无损检测专业1人；
华能集团所属电厂： 华能丹东电厂华能大连电厂华能上安电厂华能德州电厂华能威海电厂华能济宁电厂华能日照电厂华能太仓电厂华能淮阴电厂华能南京电厂华能南通电厂华能上海石洞口第一电厂华能上海石洞口第二电厂华能长兴电厂华能福州电厂华能汕头燃煤电厂华能汕头燃机电厂华能玉环电厂华能沁北电厂华能榆社电厂华能辛店电厂华能重庆分公司华能井冈山电厂华能平凉电厂华能岳阳电厂华能营口电厂华能邯峰电厂 大唐集团所属： 长山热电厂湖南省石门电厂鸡西发电厂洛阳首阳山电厂洛阳热电厂三门峡华阳发电公司河北马头电力公司唐山发电总厂北京大唐张家口发电总厂兰州西固热电有限公司合肥二电厂田家庵发电厂北京大唐高井发电厂永昌电厂北京大唐陡河电厂南京下关发电厂安徽淮南洛河发电厂保定热电厂略阳发电厂微水发电厂峰峰发电厂含岳城电站天津大唐盘山发电公司内蒙大唐托克托发电公司保定余热电厂华源热电有限责任公司阳城国际发电有限公司辽源热电有限责任公司四平发电运营中心长春第二热电有限公司晖春发电有限责任公司鸡西热电有限责任公司佳木斯第二发电厂台河第一电厂江苏徐塘发电有限公司安徽省淮北发电厂安徽淮南洛能发电公司安阳华祥电力有限公司许昌龙岗发电有限公司华银电力株洲发电厂华银株洲发电公司金竹山电厂华银金竹山火力发电厂湘潭发电有限责任公司湖南省耒阳发电厂灞桥热电有限责任公司灞桥热电厂陕西渭河发电厂陕西延安发电厂陕西韩城发电厂永昌发电厂甘肃甘谷发电厂甘肃八0三发电厂甘肃连城发电厂甘肃兰西热电有限公司广西桂冠电力股份公司桂冠大化水力发电总厂广西岩滩水电厂陈村水力发电厂王快水电厂张家界水电开发公司贺龙水电厂鱼潭水电厂陕西石泉水力发电厂石泉发电有限责任公司甘肃碧口水电厂百龙滩电厂华电所属： 1中国华电工程(集团)有限公司2华电煤业集团有限公司3华电财务有限公司4华电招标有限公司5华信保险经纪有限公司6北京华信保险公估有限公司7河北热电有限责任公司8包头东华热电有限公司（在建）9内蒙古华电乌达热电有限公司（在建）10华电国际电力股份有限公司11华电国际电力股份有限公司邹县发电厂（扩建）12华电国际电力股份有限公司莱城发电厂13华电国际电力
青热电〔2010〕121号 青岛热电集团有限公司 关于实施供热计量收费工作的意见 各单位、处室： 为全面贯彻《山东省物价局、山东省住房和城乡建设厅关于推进供热计量改革的指导意见》，根据青热办【2010】25号文件要求，自2010年开始，新供热建筑及完成供热计量改造的既有居住建筑，取消以面积计价收费，实行按用热量计价收费，为做好供热计量收费工作，经研究确定以下实施意见： 一、实施计划 （一）对已经改造完成的既有居住建筑实施供热计量收费，明细如下：第一热力海信慧谷、丰华园、弘信花园、都市名家小区；第二热力公司天宝苑小区；金河热力公司荣馨苑小区。
（二）对新竣工非居住建筑全面按用热量计量收费。 二、实施措施： （一）加强组织领导，责任到位。 职责明确，责任到人。集团成立以董事长为组长，总经理为副组长的供热计量工作领导小组，工程开发处、生安处、财务处、服务处各司其职，全力做好供热计量收费实施工作。各所属生产单位必须成立工作领导小组，将宣传、收费、数据公示、政策答疑等工作落实到位，各单位要有专门的供热计量工作负责人。 （二）措施到位，计划周密。 责任部门要全力做好实施热计量收费工作的计划安排，配合相关科室做好用户协调、宣传、合同签订、数据公示以及收、退费工作。 （三）做好新建、竣工项目供热计量设施的管理工作。各相关部门要严格新建、在建、新竣工项目供热计量设施的审核、把关、验收和问题汇总工作。 三、工作要求 （一）做好用户宣传、解释工作。在张贴用户通知进行宣传的同时，相关人员要明确供热计量工作实施相关要求规定，收费方式以及供热调节方式等，做好对用户的宣传解释工作，让用户明白调节方式和收退费方式、时间等。 （二）做好用户结算工作。用户的供热计量数据要真实、准确，各单位要认真做好用户仪表底数（正式供热时间和停止供热时间）确认工作，并定时张贴通知公开热量数据。 （三）做好数据分析和总结。对供热数据按周期进行定
1建设项目概况 1.1建设项目背景及建设地点 1.1.1建设项目背景 青岛钢铁有限公司（以下简称青钢）始建于1958年，位于青岛市北李沧区，属城市钢铁厂。厂区东邻重庆路、南渠村；西围墙距胶济铁路约85m；北距流亭国际机场约3.8km；南靠遵义路。距市中心约15km，厂内铁路专线与胶济铁路娄山站接轨，全厂总占地面积不足1.3km2。 青钢是集焦化、烧结、炼铁、炼钢、轧钢、发电等为一体的钢铁联合企业，是山东省重要的优质棒线材生产基地，山东省三大钢铁支柱企业。 目前，青钢已形成年产铁、钢、材各400×104t的生产能力。其主要生产设施有：60×104t焦化厂；2×50m2烧结机，2×105m2烧结机；5×500+1×625m3高炉；一炼钢有4×35t转炉，5座30tLF精炼炉，3台4机4流R5m小方坯连铸机和1台4机4流R8m连铸机；二炼钢有2×80t 顶底复吹转炉，3座90tLF精炼炉，1座90tRH精炼炉，2台6机6流R9m 连铸机；轧钢车间有1＃、2＃、3＃高速线材车间，复二重线材车间，半连续小型车间，横列式小型车间，还有与之配套的相应公辅设施。 青钢产品有：热轧盘条，热轧带肋钢筋、圆钢、扁钢等型钢。主要品种有：焊接用钢盘条、汽车用弹簧扁钢、硬线盘条、冷镦钢、PC钢棒用线材、拉丝线材、易切削钢、优质碳素结构圆钢、建筑用线材与螺纹钢等。2011年，青钢生产生铁330.69×104t、钢318.27×104t、钢材301.99×104t。2011年工业总产值297.79亿元，工业销售产值299.47亿元。青钢现有产品以优特钢为主，品种结构具有特色，产品附加值高。青钢现有职工1万余人，其中各类工程技术人员约1500余人。 自1997年以来，青钢经过不断的技术改造，其生产能力和经济效益均有了较大幅度的提高，但由于历史原因，还存在许多问题，如产品结构性矛盾仍